Re: Multi tenancy : schema vs databases

Поиск
Список
Период
Сортировка
От Vick Khera
Тема Re: Multi tenancy : schema vs databases
Дата
Msg-id CALd+dccruVQXNY4earcb7bQXe6XOHAbajAhNphBYjwaQJP0_Kw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Multi tenancy : schema vs databases  (Rakesh Kumar <rakeshkumar464@outlook.com>)
Ответы Re: Multi tenancy : schema vs databases  (Paul Jungwirth <pj@illuminatedcomputing.com>)
Список pgsql-general
On Fri, Sep 30, 2016 at 6:06 AM, Rakesh Kumar
<rakeshkumar464@outlook.com> wrote:
> A typical fear mongering Q from
> them "what if due to a bug in your s/w, our competitors end up looking at our data" or
> something like that. That's why schema level vs db level discussion.

So... if your software isolates customers based on a "customer_id"
field in a table, how is that less secure than isolating a customer
based on the schema? Ie, you've just moved the customer_id field from
a column to part of the table name itself. One step up from that, what
keeps your software from selecting the wrong customer_id database name
too? See, it is all just *where* you put the distinguishing name...

For your resource question, having multiple DBs require each to have
its own handle within your app. When you have many simultaneous users,
you have lots and lots of file handles to manage. You want to minimize
the number of connections to the postgres server itself.


В списке pgsql-general по дате отправления:

Предыдущее
От: Vick Khera
Дата:
Сообщение: Re: Multi tenancy : schema vs databases
Следующее
От: Colin Morelli
Дата:
Сообщение: Re: Multi tenancy : schema vs databases