Class Table Inheritance vs. Denormalization

Question

I'm trying to model a specialization/generalization, leaning towards using class table inheritance (see this answer).

However, my co-worker has maintenance and performance concerns because there will be many (50+) overlapping specializations of the same table. His suggestion is to create a table with the following columns:

• Reference to the general table
• Reference to a table that maintains types of specializations
• Reference to a table that maintains attribute values

That way all of the attributes are maintained in one table, and can be filtered by the specialization column. I don't know what this design is called, but I'm worried that it's somehow related to EAV...

My main concern is modification anomalies, but besides that I'm not seeing any reason it's a bad idea. Is one solution clearly superior to the other, or should we just pick one and move on?

Answer 1

When designing tables I usually design them with one thing in mind: usage.

How will I write the data there and how will I query it back. I bias the design toward reads or writes based on which will be more important for performance, how repetitive, etc.

Your question does not really explain your usage, so all suggestions in my answer here are complete speculation. If you insert 20k rows a day the design would be different than if you insert 5 a day. Also if you need to run 20k searches per day on any column of any type or if you run 5 a day. these would affect how you set up your tables.

With that said, a general approach might be to do something like this:

The 50+ overlapping specializations tables will be a nightmare to write queries on. I would try to come up with 1 main general table and maybe 5 or so other general tables where you might dip a little into "Single Table Inheritance" (where you may have several columns that do not apply to each type, but are included so you cover as many columns from as many types as possible). From there cover the remaining columns with the EAV like approach.