> But in all likelihood it means no one knows wtf this table actually represents and you should be firing people. That's almost exactly the opposite of my expe

> But in all likelihood it means no one knows wtf this table actually represents and you should be firing people. That's almost exactly the opposite of my experience, but then I've worked on smaller teams with long-term team members, so perhaps that's why. Our tables are wide because law require we store the data for 10 years, and it's easier and faster to store things in a single row, rather than spread out over several dozen detail tables. We don't denormalize in the sense of storing only invoice items, repeating the head data on each item. We do denormalize in the sense of storing full name and address for each party rather than storing that in a detail table. So minimal, if any, duplication of data. If we duplicate it's almost always due to the law, ie data might change in one table but shouldn't be changed in the other to preserve history. For child tables we always have a unique ID, sequence or autoinc, and the FK to the parent, but we include the root-level ID as well. This way we can select all the child rows in a single select regardless of level, again without tons of joins. This way our core data is just a handful of tables, and there's not much doubt about what goes where.