Re: Changing the concept of a DATABASE
От | Simon Riggs |
---|---|
Тема | Re: Changing the concept of a DATABASE |
Дата | |
Msg-id | CA+U5nM+_K0u2ooEom5XtOzRyPhOsMFXqqxPb9AV4zv=KBg6ASA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Changing the concept of a DATABASE (José Luis Tallón <jltallon@nosys.es>) |
Ответы |
Re: Changing the concept of a DATABASE
|
Список | pgsql-hackers |
On 22 May 2012 12:05, José Luis Tallón <jltallon@nosys.es> wrote: > IMVHO: s/database/schema/g does resolve many of the problems that you were > referring to... and 'dblink' should solve the rest, right? > Please, feel free to point out what I am (most probably) not considering -- > not experienced enough yet :) The choice of schema/database is an important one. If you get it wrong, you are in major difficulty. In many cases schemas would be a better choice, but not in all cases. So I'm interested in solving the problems for people who have multiple databases on same server. dblink is the only solution, but its very poor way to do this when we have 2 databases on same server. My thinking is that reaching out to multiple databases is actually mostly easy, except in a few places where dbid is hardwired into the backend. > On the other hand, the separation of databases allows what otherwise would > only be possible by using multiple instances of the database server (à la > Oracle, AFAIK ) -- save for resource management, but that is another > question whatsoever. Separation of databases is fine. I have no intention to change that, as long as the user wishes that. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: