5 ms·

The author advocates starting with database design before software. Some other people advocate the opposite: the database is just a detail. I think the point i

The author advocates starting with database design before software. Some other people advocate the opposite: the database is just a detail. I think the point is to spend time in designing a good domain model regardless of how it's stored (database).

zzzcpan 8y ago
Or all of them are wrong. You can't really get to a good model before you have a working software in production and before you learn about many of your broken assumptions.
- UlisesAC4 8y ago
  What about a top to bottom and then a bottom to top design ?
  - zzzcpan 8y ago
    Top-down or bottom-up, they still don't validate any assumptions. You can spend years on design stage unable to come up with anything that actually works well for the client.
    - Izkata 8y ago
      > > and then I believe Ulises is talking about two stages: Top-down a prototype to shake out bad assumptions, then bottom-up main development for a solid foundation.
wvenable 8y ago
I also always start with the "database" design or the storage model or whatever you want to call it. If you do database design with proper foreign key relationships, etc, the entire rest of the design including the UI and most of the business rules can all flow directly from that. You can also do that with a good domain model but the rigors of actually having to physically construct it in a database ensures less mistakes. Now, if you're using a loosy-goosy JSON blog storage solution than there is no advantage to starting at that level.
- EpicEng 8y ago
  Eh... I don't know. Each approach has its advantages, but in my experience, I usually have an easier time when I start with the domain model and application logic. More often than not my initial assumptions are wrong and I have to change the model. Easier to change the code than the DB as well as the code. If I hit a weird structural issue than I can usually just rewrite that but in isolation.
  - wvenable 8y ago
    I find I can tease out better assumptions and requirements by starting with the model. You immediately need answers to vital questions (more than one address, how are items related, etc). It's so valuable, I can't imagine starting any contentious project without doing that. If my assumptions are wrong, I go back the model and change that and reflow the changes back through the rest of product. It's again usually pretty easy and mechanical to make those changes once the model is again correct.
    - EpicEng 8y ago
      Yep, it can go the other way as well. I'm not religious on this one. I know what my experience has been, but those are pretty specific cases. I may change my mind next year, who knows?
- bbojan 8y ago
  "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.”
  - mooreds 8y ago
    https://en.wikiquote.org/wiki/Fred_Brooks https://en.wikiquote.org/wiki/Fred_Brooks in case anyone wanted the source.
mcrad 8y ago
As someone with a broad database development background, but with little experience shipping "software" I totally agree with the sentiment of the article. A working prototype can be as simple a handful of shell scripts that write simulation data, and that process it in the form of the primary use-cases. Iterate the core functionality from there before jumping into the more advanced engineering part(?) I cringed on this part, as perhaps an all-too-common software QA scenario: > It came down to trying to create a fake customer, with a fake order, with a fake item, with a fake item category, with a "paid" invoice, with exceptions sprinkled throughout the codebase to handle all of these special cases and probably more that I no longer remember.
nradov 8y ago
Another approach is to start with designing a logical data model first before the database schema or software. This helps avoid the trap of focusing too much on the implementation details of any particular technology.
marcosdumay 8y ago
You start by defining your types (including your database design), proceed to defining your APIs, and only then start writing your software. (Ok, and before any of that you define your problem.) You can do it iteratively, but simply inverting the order is a recipe for a mess of spaghetti that nobody will be able to touch in a just a couple of months.
partisan 8y ago
I came here to say this. This is a case of bad design and it goes beyond database constraints. One, as you mentioned, the database schema seems to be driving the functionality, not the other way around. Two, the application is a monolith in the worst way possible. Marketing and order entry are two completely different domains. Pigeonholing then into one means you don’t exactly capture the requirements of either domain correctly. The discussion is a good one to have, but it needs to happen at a level above where it currently is.
qubax 8y ago
> The author advocates starting with database design before software. Some other people advocate the opposite: the database is just a detail. If the database is just a detail then you most likely are working on a small toy project. Or a class project. If it is a significant project where performance, scale and security matter, then database is the central concern. You have to start and end with the database. But dealing with data can be boring and cumbersome so we tend to jump to coding and proscrastinate on database and data design.
- fogetti 8y ago
  I watched the clean coder videos a few years ago and Uncle Bob said the exact same thing: the DB is just detail. I am not saying that he was right and I am not going to argue for his approach but it seems some of the big shots of the industry agree that DB is not central to the design. Also see: https://8thlight.com/blog/uncle-bob/2012/05/15/NODB.html https://8thlight.com/blog/uncle-bob/2012/05/15/NODB.html > Databases and frameworks are details!

zzzcpan 8y ago

Or all of them are wrong. You can't really get to a good model before you have a working software in production and before you learn about many of your broken assumptions.

UlisesAC4 8y ago
What about a top to bottom and then a bottom to top design ?
- zzzcpan 8y ago
  Top-down or bottom-up, they still don't validate any assumptions. You can spend years on design stage unable to come up with anything that actually works well for the client.
  - Izkata 8y ago
    > > and then I believe Ulises is talking about two stages: Top-down a prototype to shake out bad assumptions, then bottom-up main development for a solid foundation.

wvenable 8y ago

I also always start with the "database" design or the storage model or whatever you want to call it. If you do database design with proper foreign key relationships, etc, the entire rest of the design including the UI and most of the business rules can all flow directly from that. You can also do that with a good domain model but the rigors of actually having to physically construct it in a database ensures less mistakes. Now, if you're using a loosy-goosy JSON blog storage solution than there is no advantage to starting at that level.

EpicEng 8y ago
Eh... I don't know. Each approach has its advantages, but in my experience, I usually have an easier time when I start with the domain model and application logic. More often than not my initial assumptions are wrong and I have to change the model. Easier to change the code than the DB as well as the code. If I hit a weird structural issue than I can usually just rewrite that but in isolation.
- wvenable 8y ago
  I find I can tease out better assumptions and requirements by starting with the model. You immediately need answers to vital questions (more than one address, how are items related, etc). It's so valuable, I can't imagine starting any contentious project without doing that. If my assumptions are wrong, I go back the model and change that and reflow the changes back through the rest of product. It's again usually pretty easy and mechanical to make those changes once the model is again correct.
  - EpicEng 8y ago
    Yep, it can go the other way as well. I'm not religious on this one. I know what my experience has been, but those are pretty specific cases. I may change my mind next year, who knows?
bbojan 8y ago
"Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.”
- mooreds 8y ago
  https://en.wikiquote.org/wiki/Fred_Brooks https://en.wikiquote.org/wiki/Fred_Brooks in case anyone wanted the source.

mcrad 8y ago

As someone with a broad database development background, but with little experience shipping "software" I totally agree with the sentiment of the article. A working prototype can be as simple a handful of shell scripts that write simulation data, and that process it in the form of the primary use-cases. Iterate the core functionality from there before jumping into the more advanced engineering part(?) I cringed on this part, as perhaps an all-too-common software QA scenario: > It came down to trying to create a fake customer, with a fake order, with a fake item, with a fake item category, with a "paid" invoice, with exceptions sprinkled throughout the codebase to handle all of these special cases and probably more that I no longer remember.

nradov 8y ago

Another approach is to start with designing a logical data model first before the database schema or software. This helps avoid the trap of focusing too much on the implementation details of any particular technology.

marcosdumay 8y ago

You start by defining your types (including your database design), proceed to defining your APIs, and only then start writing your software. (Ok, and before any of that you define your problem.) You can do it iteratively, but simply inverting the order is a recipe for a mess of spaghetti that nobody will be able to touch in a just a couple of months.

partisan 8y ago

I came here to say this. This is a case of bad design and it goes beyond database constraints. One, as you mentioned, the database schema seems to be driving the functionality, not the other way around. Two, the application is a monolith in the worst way possible. Marketing and order entry are two completely different domains. Pigeonholing then into one means you don’t exactly capture the requirements of either domain correctly. The discussion is a good one to have, but it needs to happen at a level above where it currently is.

qubax 8y ago

> The author advocates starting with database design before software. Some other people advocate the opposite: the database is just a detail. If the database is just a detail then you most likely are working on a small toy project. Or a class project. If it is a significant project where performance, scale and security matter, then database is the central concern. You have to start and end with the database. But dealing with data can be boring and cumbersome so we tend to jump to coding and proscrastinate on database and data design.

fogetti 8y ago
I watched the clean coder videos a few years ago and Uncle Bob said the exact same thing: the DB is just detail. I am not saying that he was right and I am not going to argue for his approach but it seems some of the big shots of the industry agree that DB is not central to the design. Also see: https://8thlight.com/blog/uncle-bob/2012/05/15/NODB.html https://8thlight.com/blog/uncle-bob/2012/05/15/NODB.html > Databases and frameworks are details!