5 ms·

This isn't about database design, per se, it's about data model design in general. Starting a software project by thinking hard about the data model is always

This isn't about database design, per se, it's about data model design in general. Starting a software project by thinking hard about the data model is always good advice, but even knowing this it is almost always impossible to design things perfectly up front. You need to hit problems square on in practice, and reshape your model to deal with them. If you think otherwise, if you really think you can think through in advance all the possible unexpected permutations of how your model might not work in practice, like with this address thing, you are just kidding yourself. It never happens that way. So, maybe the best advice is not only to start by thinking about the data model but to have a mindset of continually thinking about and changing your data model, and to build your software using languages, tools and technologies that better accomodate this.

sooheon 8y ago
Yeah, I think you're correct to point out the tension between designing up front and adapting to reality you learn as you go. If you haven't been exposed already, the way Datomic approaches this problem has been eye-opening for me: https://docs.datomic.com/on-prem/best-practices.html#plan-for-accretion https://docs.datomic.com/on-prem/best-practices.html#plan-fo...
thirdsun 8y ago
I agree and I'm surprised potential data models aren't as often discussed and debated as the choice of technology and stacks. At least to me considering and planning a lasting data model, despite knowing that it'll change, is a far more significant focus than choosing a framework - a choice which is often dictated by your experience and familiarity with those options anyway. And yet we rarely see discussions about best practices when it comes to data models. Maybe the requirements and solutions are often too specific.
- dvfjsdhgfv 8y ago
  > I agree and I'm surprised potential data models aren't as often discussed and debated as the choice of technology and stacks. This. People can discuss stacks and tools for hours, whereas the optimal data model seems to be a boring topic, even though very often it turns out far more important in the long run.
misakwa 8y ago
It might have helped to model an account system where customers belonged to accounts and addresses belonged to accounts. Customers can then have multiple addresses by their association to the account and the unique constraint (if required) could have been applied on the account<->address relationship.

sooheon 8y ago

Yeah, I think you're correct to point out the tension between designing up front and adapting to reality you learn as you go. If you haven't been exposed already, the way Datomic approaches this problem has been eye-opening for me: https://docs.datomic.com/on-prem/best-practices.html#plan-for-accretion https://docs.datomic.com/on-prem/best-practices.html#plan-fo...

thirdsun 8y ago

I agree and I'm surprised potential data models aren't as often discussed and debated as the choice of technology and stacks. At least to me considering and planning a lasting data model, despite knowing that it'll change, is a far more significant focus than choosing a framework - a choice which is often dictated by your experience and familiarity with those options anyway. And yet we rarely see discussions about best practices when it comes to data models. Maybe the requirements and solutions are often too specific.

dvfjsdhgfv 8y ago
> I agree and I'm surprised potential data models aren't as often discussed and debated as the choice of technology and stacks. This. People can discuss stacks and tools for hours, whereas the optimal data model seems to be a boring topic, even though very often it turns out far more important in the long run.

misakwa 8y ago

It might have helped to model an account system where customers belonged to accounts and addresses belonged to accounts. Customers can then have multiple addresses by their association to the account and the unique constraint (if required) could have been applied on the account<->address relationship.