Question

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.

Answer 1

Definitely the former example. Do you want to be adding tables to your database whenever you add a new model to your product range?