Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

7
  • 11
    Resistance to the single table weltanschauung often comes from those inexperienced with SQL who don't understand joins - especially with regards to missing data i.e. outer joins. Commented Apr 26, 2016 at 15:56
  • 6
    @RobbieDee More commonly, it's from people who have seen denormalized data get corrupted by becoming inconsistent. I am one such person. I would only consider this kind of structure in the situation Phill suggests: this is some kind of logging/reporting table where data will never be updated or only updated by being wiped clean and completely re-derived from other sources. Commented Apr 27, 2016 at 1:05
  • 2
    Even if the application performs acceptably with a database like this, it's still not flexible like a properly normalized database. If the store name or company name change, it will have to be updated everywhere, instead of in just a store or company table. In some cases, that may actually be what you want (such as if the data is mainly collected for archival purposes), but we'd need to know more about the specific application. Commented Apr 27, 2016 at 5:36
  • 1
    @Zach: agreed, that's why the sales log is potentially an acceptable case for this. Supposing you want each sale to be associated with whatever the store was named at the time the sale was made, not "the current name of the store", then attempting to "normalise" this introduces some considerable complexity (because the table recording store names would need to be a series over time, not just one value per storeid) Commented Apr 27, 2016 at 18:02
  • Perhaps a rule of thumb would be that if the only complexity introduced by a proposed normalisation is that a few queries now need joins in them to pick up all the columns they need to report, then you should run not walk to make that change :-) Commented Apr 27, 2016 at 18:05