3 ms·

But then why not addressing the real problem? If a table has a few columns which are not used or invalid or deceiving, why did we let developers introduce them?

But then why not addressing the real problem? If a table has a few columns which are not used or invalid or deceiving, why did we let developers introduce them? Lack of planning? Lack of peer review? Lack of talent? I understand these “ten rules” as: as long as you have a decent codebase and decent engineers, these ten rules will make your life easier. These rules are nothing if you are dealing with crap codebases (they can help, sure, but they will be just patches)

striking 3y ago
Because sometimes you make assumptions that are seemingly correct but eventually found to be wrong or based on flawed inputs from sources beyond your control. Any system that ultimately relies on "engineers need to always do the right thing" is a flawed, brittle, ineffectual system. Because even the best engineers will make a mistake somewhere, and because you can't exclusively hire "the best" engineers. Let's spend our time figuring out how to recover from mistakes rather than trying to pretend they'll never happen.
phtrivier 3y ago
Even the best team make design decision that turns out suboptimal when the requirement changes. Also, even the best team will sometimes make mistake. Db schemas are unforgiving.
__jem 3y ago
I've worked with some databases that are 20+ years old and have outlived multiple application iterations. There's always going to be cruft in this kind of situation, it just comes with territory of supporting applications with real production users for a long time.
yxhuvud 3y ago
Requirements change over time. Domain understanding change over tim. Business change over time. Environments change over time. Unless you are a seer with perfect precognition, most of what you have done will be invalidated over time. Hence: make your code and data easy to change, but simple, as you cannot predict in what way it will change.
- Swizec 3y ago
  > Unless you are a seer with perfect precognition Even then ain't nobody in a 10 person seed-stage startup got time, resources, or need to build the database you'll want to have when you're a 600 person Series C monster.
butlerm 3y ago
Developers without special training should generally not do database design for the sort of databases that are intended to last decades. It is a similar task to developing a complex file format that is usable twenty years later - not something to be done off the cuff, and if you want schema stability database design requires more care than most file formats.
- sgarland 3y ago
  While I agree with you, unfortunately this is unrealistic. Unless a startup happens to have someone skilled with schema design, they’re going to make do with what they can, and it’s very unlikely that they’d waste headcount on a dedicated DBA / DBRE at a young stage. The immediate effect of that, of course, is that they also won’t try to hire any such person until the DB is a problem they can’t scale via throwing money at it.

striking 3y ago

Because sometimes you make assumptions that are seemingly correct but eventually found to be wrong or based on flawed inputs from sources beyond your control. Any system that ultimately relies on "engineers need to always do the right thing" is a flawed, brittle, ineffectual system. Because even the best engineers will make a mistake somewhere, and because you can't exclusively hire "the best" engineers. Let's spend our time figuring out how to recover from mistakes rather than trying to pretend they'll never happen.

phtrivier 3y ago

Even the best team make design decision that turns out suboptimal when the requirement changes. Also, even the best team will sometimes make mistake. Db schemas are unforgiving.

__jem 3y ago

I've worked with some databases that are 20+ years old and have outlived multiple application iterations. There's always going to be cruft in this kind of situation, it just comes with territory of supporting applications with real production users for a long time.

yxhuvud 3y ago

Requirements change over time. Domain understanding change over tim. Business change over time. Environments change over time. Unless you are a seer with perfect precognition, most of what you have done will be invalidated over time. Hence: make your code and data easy to change, but simple, as you cannot predict in what way it will change.

Swizec 3y ago
> Unless you are a seer with perfect precognition Even then ain't nobody in a 10 person seed-stage startup got time, resources, or need to build the database you'll want to have when you're a 600 person Series C monster.

butlerm 3y ago

Developers without special training should generally not do database design for the sort of databases that are intended to last decades. It is a similar task to developing a complex file format that is usable twenty years later - not something to be done off the cuff, and if you want schema stability database design requires more care than most file formats.

sgarland 3y ago
While I agree with you, unfortunately this is unrealistic. Unless a startup happens to have someone skilled with schema design, they’re going to make do with what they can, and it’s very unlikely that they’d waste headcount on a dedicated DBA / DBRE at a young stage. The immediate effect of that, of course, is that they also won’t try to hire any such person until the DB is a problem they can’t scale via throwing money at it.