Old, Good Database Design
relinx.io
Old, Good Database Design
1–10 of 167 posts
Re: Old, Good Database Design
#2> A well-thought design can save us many hours of coding, testing, and troubleshooting.
That is the very definition of a waterfall design model.
I've turned into a fluid-design advocate over the years, where every design principle follows a next question - "okay, this is good but how would I change it?".
So you start with a unique constraint and four months later, you find out that it is not actually unique (like "two patients with the same email, because the 2nd one is a newborn on day of birth").
Or you normalize a data-set only to find out that your 1:N relationship turns into a 2:N relationship from before/after dates (like "UK" goes from "EU" to "UK").
The lost-time work of a design is usually the "okay, we did it in a world where UK was in EU - but we undo it & here's how" notes.
Having a plan to decommission the nuclear plant you're building is super useful and often more relevant than designing it for efficiency alone.
Re: Old, Good Database Design
#3This is useful for most small apps or truly monolithic apps. ...But normalization in a distributed environment with 50+ apps? Really? You need to have some sort of duplication unless you want big bottlenecks, performance penalties, and hot headaches
From the linked MS article: "Redundant data wastes disk space and creates maintenance problems"
Made me laugh well
Re: Old, Good Database Design
#4> A well-thought design can save us many hours of coding, testing, and troubleshooting. That is the very definition of a waterfall design model. I've turned into a fluid-design advocate over the years, where every design principle follows a next question - "okay, this is good but how would I change it?". So you start with a unique constraint and four months later, you find out that it is not actually unique (like "tw…
Good design as advocated by the author is generally conducive to change and is saying pretty much the same thing as you are.
It's a lot easier to take away unique constraints later on instead of adding them in. It's easier to de-normalize some data for performance than to normalize it later on. The list goes on.
The reason the waterfall method received so much bad press is because of requirements gathering, not the software or data design phases. Requirements are hard to get right the first time and they also change over time. But I'd be surprised to find someone argue that good architecture and design is a bad thing (being defined as the ability to adapt to changes in requirements).
Re: Old, Good Database Design
#5> A well-thought design can save us many hours of coding, testing, and troubleshooting. That is the very definition of a waterfall design model. I've turned into a fluid-design advocate over the years, where every design principle follows a next question - "okay, this is good but how would I change it?". So you start with a unique constraint and four months later, you find out that it is not actually unique (like "tw…
When you need to add info to your database, do you refactor existing tables or do you add a key-value table.
I've seen so many key-value tables that really needed to be refactored into proper normalized tables.
It's just so tempting to stick extra info into KV when you don't know where the project will end up.
Re: Old, Good Database Design
#6> A well-thought design can save us many hours of coding, testing, and troubleshooting. That is the very definition of a waterfall design model. I've turned into a fluid-design advocate over the years, where every design principle follows a next question - "okay, this is good but how would I change it?". So you start with a unique constraint and four months later, you find out that it is not actually unique (like "tw…
Are you presuming that a 'well-thought [out] design' means that all the thoughts, and the design, came only at first? I can see a well-thought out design either as the waterfall you presume, or as an accretion of design decisions made over time as in your 'fluid design.' Either way can save many hours of coding, testing, troubleshooting.
Re: Old, Good Database Design
#7> A well-thought design can save us many hours of coding, testing, and troubleshooting. That is the very definition of a waterfall design model. I've turned into a fluid-design advocate over the years, where every design principle follows a next question - "okay, this is good but how would I change it?". So you start with a unique constraint and four months later, you find out that it is not actually unique (like "tw…
Good design as advocated by the author is generally conducive to change and is saying pretty much the same thing as you are. It's a lot easier to take away unique constraints later on instead of adding them in. It's easier to de-normalize some data for performance than to normalize it later on. The list goes on. The reason the waterfall method received so much bad press is because of requirements gathering, not the s…
> The reason the waterfall method received so much bad press is because of requirements gathering, not the software or data design phases.
No, it was because all three were done wrong.
Requirements gathering is the biggest problem, true. But even if requirements were both knowable and fixed, for most projects, big up front requirements gathering, design, and then implementation would have lots of waste in the lean sense of effort expended that spends time not delivering customer value.
Now, that gets made worse with the rework created by the fact that requirements gathering without validation by use gets lots of stuff wrong and that the context is often evolving such that requirements will drift between gathering, design, and implementation in a waterfall project, so that lots of work is done which never delivers value and needs reworked before it can do so, but the problem exists even without that exacerbation.
Re: Old, Good Database Design
#8My least favorite part of database design is the bit where you have to pick lengths for your char columns.
Twenty years in and I'm still picking these pretty much by guessing. And when I guess wrong it causes really annoying problems further down the line.
I love how SQLite doesn't make me do this - it just has a TEXT type which is always unlimited in length.
Re: Old, Good Database Design
#9This is useful for most small apps or truly monolithic apps. ...But normalization in a distributed environment with 50+ apps? Really? You need to have some sort of duplication unless you want big bottlenecks, performance penalties, and hot headaches From the linked MS article: "Redundant data wastes disk space and creates maintenance problems" Made me laugh well
> You need to have some sort of duplication unless you want big bottlenecks, performance penalties
I think that's called a cache. You can still have solid database design at the core. Then add redis on top of it.
Re: Old, Good Database Design
#10This is useful for most small apps or truly monolithic apps. ...But normalization in a distributed environment with 50+ apps? Really? You need to have some sort of duplication unless you want big bottlenecks, performance penalties, and hot headaches From the linked MS article: "Redundant data wastes disk space and creates maintenance problems" Made me laugh well
Duplication is OK provided there are strict, documented rules about which copy is the "point of truth". If the duplicates diverge you need to know how to fix them.