Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Nikhil1home
Starting Member
23 Posts |
 Posted - 2011-08-08 : 21:58:44
|
| Guys, I have a temp-to-perm offer for customizing and implimenting a vendor application that has thousands of database tables(7500 tables to be exact, of which half are audit tables. One audit table for each working table.) My first impression is that this is a very poor database design. Do you guys think the same way? I don't want to be too judgemental from the beginning. In your opinion, could there be any possible good reasons for such a database design? |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
|
|
Nikhil1home
Starting Member
23 Posts |
Posted - 2011-08-08 : 22:35:00
|
quote:
Originally posted by tkizer
We can't say if it's poor design or not with the information provided. If it's properly normalized, then it's perhaps good design. Number of tables doesn't mean bad or good design. Hopefully they've organized the objects somewhat, perhaps via schemas.Tara KizerMicrosoft MVP for Windows Server System - SQL Serverhttp://weblogs.sqlteam.com/tarad/Subscribe to my blog
Hi Tara, this is the only information I have. Honestly, I can't imagine any application requiring this many tables. What do you think the possible reasons may be for having so many tables? Have you come across such a database? |
 |
|
|
flamblaster
Constraint Violating Yak Guru
384 Posts |
Posted - 2011-08-08 : 23:18:05
|
| Hi Nik,I'm not a DBA, but I can comment on the product that I use. We have a proprietary transit software application that runs on approximately 600 tables "WITHOUT" the history tables in effect. Any table can have a history table added to capture changes as needed. So theoretically, we could have 1200 or so tables for the application if we enabled (created) a history table for each.The software is essentially an ERP system for transit. It includes algorithms for efficient scheduling of demand responsive transportation as well as fixed route tranportation. Those two activities by themselves use about 300 tables. There there is an automatic export to our payroll system based on hours worked. There's driver performance evaluations which include attendance, accidents, incidents etc etc. The list goes on. I can't imagine the application having less tables than it has. Actually, from time to time, I wonder why they didn't go into further depth with some of their table structure.This is only one industry, imagine if you had, say an ERP system for a whole City government (which we also use) or a large corporation. I don't have access to our city wide ERP system, but I know it's vast. |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
|
|
|
|
|
|
|
thousands of tables in a database