Re: Many little databases or one big one?
От | Ron Johnson |
---|---|
Тема | Re: Many little databases or one big one? |
Дата | |
Msg-id | 1052220601.3368.270.camel@haggis обсуждение исходный текст |
Ответ на | Many little databases or one big one? (Jason Hihn <jhihn@paytimepayroll.com>) |
Список | pgsql-general |
On Mon, 2003-05-05 at 15:04, Jason Hihn wrote: > In all likelihood, I will be admin'ing several hundred databases whose > schema is identical. Being the lazy admin that I am, I was thinking that it > may be better for me to combine everything into one large database and just > make views for each former database (after appending a key to each table, > and appropriately naming the view). This would be much more manageable, > since db objects (procedures, triggers, table schemas) would update for all > at once. My developer team is changing things pretty frequently too. To > enforce version consistency through all the databases, this would be the > best and easiest way to do that. > > What are the down sides? I know that I can no longer partition the data into > separate directories. A table corruption would effect everyone. More data > needs to be stored (addt'l keys). Are there other downsides? If there are > too many down sides, is there an easier way I can update the db objects (a > tool) for each DB all at once? Wouldn't most indexes also have to have the logical_key prepended to it, to help isolate the data? Otherwise, data would "bleed over" between "systems". Also, since the developers would only see views, how would they use the logical_key in their queries so that they are efficient? -- +---------------------------------------------------------------+ | Ron Johnson, Jr. mailto:ron.l.johnson@cox.net | | Jefferson, LA USA http://members.cox.net/ron.l.johnson | | | | The purpose of the military isn't to pay your college tuition | | or give you a little extra income; it's to "kill people and | | break things". Surprisingly, not everyone understands that. | +---------------------------------------------------------------+
В списке pgsql-general по дате отправления: