Is it ever good design to have duplicate tables?

wxdqz

New Member
1) Is it ever good database design practice (for speed sake, etc.) to essentially make copies of tables to hold a certain group of data? For example, I have come across a database table that stores information for a housing subdivision; ie. lot number, lot size, lot price, etc. And the database to which this table belongs stores this data for many subdivisions. However, instead of having one table that stores the subdivision
information for ALL subdivisions (and having some ID that represents the specific subdivision), this database has one table for each subdivision. For example, 'Clair Ridge Estates Subdivision Info' and another table 'Possum Bend Subdivision Info', etc, with each table having the exact same fields. And, if they needed another subdivision, they would make yet another copy and give it a unique name.

2) Suppose I was opening a web site that provided online accounting software to businesses (such as netledger.com). So one day, I may have 3 business subscribing and the next day 2 more may subscribe. Is it best to store all of these customer's information (invoices, customers, employees, accounts payables) together in the same database and tables? Or, is it best to make a database for each of the customers and store this db name so the software would connect to the correct database for a given user?
 
Back
Top