Let's say you are a GM dba and you have to design around the GM models
Is it better to do this?
- table_model
- type {cadillac, saturn, chevrolet}
Or this?
- table_cadillac_model
- table_saturn_model
- table_chevrolet_model
Let's say that the business lines have the same columns for a model and that there are over a million records for each subtype.
EDIT:
- there is a lot of CRUD
- there are a lot of very processor intensive reports
- in either schema, there is a model_detail table that contains 3-5 records for each model and the details for each model differ (you can't add a cadillac detail to a saturn model)
- the dev team doesn't have any issues with db complexity
- i'm not really sure that this is a normalization question. even though the structures are the same they might be thought of as different entities.
EDIT:
Reasons for partitioning the structure into multiple tables- business lines may have different business rules regarding parts- addModelDetail() could be different for each business line (even though the data format is the same)- high add/update activity - better performance with partitioned structure instead of single structure (I'm guessing and not sure here)?
I think this is a variation of the EAV problem. When posed as a EAV design, the single table structure generally gets voted as a bad idea. When posed in this manner, the single table strucutre generally gets voted as a good idea. Interesting...
I think the most interesting answer is having two different structures - one for crud and one for reporting. I think I'll try concatenated/flattened view for reporting and multiple tables for crud and see how that works.
