What's the better database design: more tables or more columns? -
a former coworker insisted database more tables fewer columns each better 1 fewer tables more columns each. example rather customer table name, address, city, state, zip, etc. columns, have name table, address table, city table, etc.
he argued design more efficient , flexible. perhaps more flexible, not qualified comment on efficiency. if more efficient, think gains may outweighed added complexity.
so, there significant benefits more tables fewer columns on fewer tables more columns?
i have few simple rules of thumb follow when designing databases, think can used make decisions this....
- favor normalization. denormalization form of optimization, requisite tradeoffs, , such should approached yagni attitude.
- make sure client code referencing database decoupled enough schema reworking doesn't necessitate major redesign of client(s).
- don't afraid denormalize when provides clear benefit performance or query complexity.
- use views or downstream tables implement denormalization rather denormalizing core of schema, when data volume , usage scenarios allow it.
the usual result of these rules initial design favor tables on columns, focus on eliminating redundancy. project progresses , denormalization points identified, overall structure evolve toward balance compromises limited redundancy , column proliferation in exchange other valuable benefits.
Comments
Post a Comment