4 ms·

Code is not that matter. It's the database design. The understanding of domain that reflects in your database design. Another way speaking, given me a well des

Code is not that matter. It's the database design. The understanding of domain that reflects in your database design. Another way speaking, given me a well designed SQL database, i could produce a working software in one day, with bad code even. Most of broken code is because of wrongly designed database, not the code itself.

whycombinater 7y ago
I second this. I seventy this. The bottom layer, designed inconsistently, will percolate through until some wrapper code renormalizes any inconsistencies. Layers and layers of junk built on junk.
- deleted 7y ago
  [deleted]
BeetleB 7y ago
Not to take away from your comment, but you do realize a huge amount of SW doesn't have any SQL database?
- revskill 7y ago
  SQL is just one example of Database. My comment is generic about storage implementation though. The same story applies to NoSQL or any other kinds of database as well.
  - jcelerier 7y ago
    you should say data model, because the majority of software in existence does not use any kind of database. No db in games, in photoshop, etc...
    - ken 7y ago
      It's telling how dominant the (R)DBMS has become, when people can't imagine "database" meaning anything else.
- Supermancho 7y ago
  To summarize Linus (sigh)...programming is about data structures. Regardless of where they or the data comes from, data transforms are what we PRIMARILY do.
barbecue_sauce 7y ago
For green field projects, specifically for commercial products, I've always felt you should design the application interface first (wireframes, use cases, dashboards, etc.), then design the ERD of a database that will support that design, then do everything in between. Everything else is just moving data around.
- revskill 7y ago
  My experience is absolutely opposite. Often, coders receive a design of Database from leaders, with SQL store procedures. Only then they will follow the mock-up and then start to code.
  - s188 7y ago
    So much goodness comes from a well designed database as you point out, but I agree with barbecue_sauce too. Do the interface mock-up first (and get the customers agreement), then do the database design and then build everything in between. The mock-up gives you a functional insight (an understanding of the problem domain) that's crucial to designing the database. Technical debt is heavily weighted to the database. Get the database design wrong and you'll be paying for years. As whycombinater says: > The bottom layer, designed inconsistently, will percolate through That's why it's so useful to get a front-end mock-up done. It's a learning exercise that's key to getting the database design right.
    - revskill 7y ago
      I know it. But you have to pay the cost. Do the mock-up, build an MVP just to get the insight from UX viewpoint. My point of view is that, it's not worth the trade-off here (especially you have only limited time-budget or dev-budget).
- dsego 7y ago
  Haha, good luck, usually the project is "agile" and experimenting and pivoting and "we'll know it when we see it" and only 7% of people are actually clicking a button so let's redesign those screens and so on.
mrkeen 7y ago
Absolutely not! The point of Dependency Inversion is that your business code doesn't know it's talking to a database.
- revskill 7y ago
  Even with Rails, i query by writing directly SQL code, instead of using ActiveRecord. Code is clean, no more layered abstraction for no purpose.
  - mrkeen 7y ago
    > no more layered abstraction for no purpose I agree with this. > i query by writing directly SQL code, instead of using ActiveRecord I haven't used ActiveRecord, but I'm sure I'd hate it and prefer direct SQL - if I were forced to choose between the two. So let me offer a third choice: an abstraction which serves an actual purpose, and is neither raw SQL nor ActiveRecord. Pretend your domain is about farming fruit. A naive design might be: FruitService -> FruitDatabase. The DI way is to change that to: FruitService -> Fruit <- FruitDatabase You effectively divide-and-conquer the problem, so that you can think about your fruity business rules in the Service, and think about fruity storage in the Database. When working in the Service, your might think about business thoughts like "We should throw away the 25% smallest green apples". When working in the Database, you might think "Do I like the amount of SQL normalisation? Did I miss any indexes? How do I model an apple at the SQL table level?" The purpose of this is to prevent you from thinking "Do I have an SQL column for colour?" when you're working on the business rules.
    - revskill 7y ago
      In your case, the logic of manipulating params to pass to SQL query doesn't change my PoV. No ORM layer when i query that "We should throw away the 25% smallest green apples". http request => controller => params manipulation => sql => database.
collyw 7y ago
“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” Apparently a quote from Linus, but I think it holds true for almost every level of the stack.

whycombinater 7y ago

I second this. I seventy this. The bottom layer, designed inconsistently, will percolate through until some wrapper code renormalizes any inconsistencies. Layers and layers of junk built on junk.

deleted 7y ago
[deleted]

BeetleB 7y ago

Not to take away from your comment, but you do realize a huge amount of SW doesn't have any SQL database?

revskill 7y ago
SQL is just one example of Database. My comment is generic about storage implementation though. The same story applies to NoSQL or any other kinds of database as well.
- jcelerier 7y ago
  you should say data model, because the majority of software in existence does not use any kind of database. No db in games, in photoshop, etc...
  - ken 7y ago
    It's telling how dominant the (R)DBMS has become, when people can't imagine "database" meaning anything else.
Supermancho 7y ago
To summarize Linus (sigh)...programming is about data structures. Regardless of where they or the data comes from, data transforms are what we PRIMARILY do.

barbecue_sauce 7y ago

For green field projects, specifically for commercial products, I've always felt you should design the application interface first (wireframes, use cases, dashboards, etc.), then design the ERD of a database that will support that design, then do everything in between. Everything else is just moving data around.

revskill 7y ago
My experience is absolutely opposite. Often, coders receive a design of Database from leaders, with SQL store procedures. Only then they will follow the mock-up and then start to code.
- s188 7y ago
  So much goodness comes from a well designed database as you point out, but I agree with barbecue_sauce too. Do the interface mock-up first (and get the customers agreement), then do the database design and then build everything in between. The mock-up gives you a functional insight (an understanding of the problem domain) that's crucial to designing the database. Technical debt is heavily weighted to the database. Get the database design wrong and you'll be paying for years. As whycombinater says: > The bottom layer, designed inconsistently, will percolate through That's why it's so useful to get a front-end mock-up done. It's a learning exercise that's key to getting the database design right.
  - revskill 7y ago
    I know it. But you have to pay the cost. Do the mock-up, build an MVP just to get the insight from UX viewpoint. My point of view is that, it's not worth the trade-off here (especially you have only limited time-budget or dev-budget).
dsego 7y ago
Haha, good luck, usually the project is "agile" and experimenting and pivoting and "we'll know it when we see it" and only 7% of people are actually clicking a button so let's redesign those screens and so on.

mrkeen 7y ago

Absolutely not! The point of Dependency Inversion is that your business code doesn't know it's talking to a database.

revskill 7y ago
Even with Rails, i query by writing directly SQL code, instead of using ActiveRecord. Code is clean, no more layered abstraction for no purpose.
- mrkeen 7y ago
  > no more layered abstraction for no purpose I agree with this. > i query by writing directly SQL code, instead of using ActiveRecord I haven't used ActiveRecord, but I'm sure I'd hate it and prefer direct SQL - if I were forced to choose between the two. So let me offer a third choice: an abstraction which serves an actual purpose, and is neither raw SQL nor ActiveRecord. Pretend your domain is about farming fruit. A naive design might be: FruitService -> FruitDatabase. The DI way is to change that to: FruitService -> Fruit <- FruitDatabase You effectively divide-and-conquer the problem, so that you can think about your fruity business rules in the Service, and think about fruity storage in the Database. When working in the Service, your might think about business thoughts like "We should throw away the 25% smallest green apples". When working in the Database, you might think "Do I like the amount of SQL normalisation? Did I miss any indexes? How do I model an apple at the SQL table level?" The purpose of this is to prevent you from thinking "Do I have an SQL column for colour?" when you're working on the business rules.
  - revskill 7y ago
    In your case, the logic of manipulating params to pass to SQL query doesn't change my PoV. No ORM layer when i query that "We should throw away the 25% smallest green apples". http request => controller => params manipulation => sql => database.

collyw 7y ago

“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.” Apparently a quote from Linus, but I think it holds true for almost every level of the stack.