Re: Multi-tenancy in Postgres

Поиск
Список
Период
Сортировка
От Radosław Smogura
Тема Re: Multi-tenancy in Postgres
Дата
Msg-id 5480ec66ff87a8c4c7e7203f512defe6@mail.softperience.eu
обсуждение исходный текст
Ответ на Re: Multi-tenancy in Postgres  (Rob Sargent <robjsargent@gmail.com>)
Ответы Re: Multi-tenancy in Postgres  (Emrul Islam <emrul@emrul.com>)
Список pgsql-general
 On Tue, 28 Jun 2011 17:04:54 -0600, Rob Sargent wrote:
> On 06/28/2011 04:52 PM, Greg Smith wrote:
>> On 06/28/2011 05:45 PM, Rob Sargent wrote:
>>> I think Greg might be forgetting that some of us don't always get
>>> to
>>> choose what we work on.  I was in a shop that decided to go with
>>> multi-tenancy for reason both technical and um, er envious.
>>
>> There are certainly successful deployments of multi-tenant
>> PostgreSQL
>> out there, ones that make sense.  What I was trying to communicate
>> is
>> that the particular variation proposed by this academic paper
>> doesn't
>> seem the right direction for PostgreSQL development to head in to
>> me.
>> This project is stubborn about resolving the problems people
>> actually
>> have, and the ones the paper tries to solve are not the ones I've
>> seen
>> in my own experiments in multi-tenant deployments.
>>
> Yes, your point is well taken here, and that wasn't even hinted at in
> my
> previous (top! oops) post.  My point was that hacks in the field
> (i.e.
> me) will have to do multi-tenancy on postgres and though this
> implementation may not become the answer, any leg up would be
> appreciated.

 I think this may be quite interesting solution. Actually I created such
 approach, for many reasons, but it's hard-coded, I mean in any place
 when query is executed I add this "tenancy" id, I called it differently,
 and it works perfectly.

 But such feature will not grow quite fast until PostgreSQL "ecosystem"
 will not grow, for example I see problems with Java + Hibernate +
 Caching, when "tenancy" id will be hidden, actually You may query for
 two "different" objects with same id, if we will allow dynamic tanacy
 switch (should be done, as You will loose connection pool benefits).

 Regards,
 Radek

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

Предыдущее
От: Sim Zacks
Дата:
Сообщение: Re: PLPGSQL SETOF functions
Следующее
От: Vincent Veyron
Дата:
Сообщение: Re: rationale behind quotes for camel case?