| Best Practices for Architecting Databases? [message #90520] |
Thu, 15 January 2004 16:50  |
Chris
Messages: 128
Registered: November 1998
|
Senior Member |
|
|
I am developing an enterprise data architecture, and need to define subject oriented databases. From earlier studies, we know that there will be 3000-5000 tables that can be logically grouped into 25-30 subject areas based on semantic relatedness.
What are best practices for deciding how many and which tables should be defined in a single database instance or schema?
|
|
|
|
| Re: Best Practices for Architecting Databases? [message #90532 is a reply to message #90520] |
Tue, 27 January 2004 11:00  |
Martyn Roberts
Messages: 9
Registered: July 2003
|
Junior Member |
|
|
From a practical development point of view I have found the following, admittedly while working on databases with 300-500 tables:
- releases get very messy when dealing with multiple inter-schema dependencies.
- your original ideas for the organization of schema can rapidly degrade when independent developers/teams start making choices about what goes where.
- a single database instance can be arranged to handle massive amounts of information and heavy use, for example by using Oracle RAC.
- transactional control across multiple database instances is an order of magnitude more complex than within a single instance.
Because of these points I have often tended towards a single instance and a low number of schema.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
