Home » Developer & Programmer » Designer » Best Practices for Architecting Databases?
Best Practices for Architecting Databases? [message #90520] Thu, 15 January 2004 16:50 Go to next message
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 Go to previous message
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.
Previous Topic: double foreign key to the same table
Next Topic: Oracle
Goto Forum:
  


Current Time: Tue Mar 19 06:08:14 CDT 2024