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. |
+---------------------------------------------------------------+
