Hacker News Reader

Comment by revskill | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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).

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.

You still need somewhere to start, though.

Absolutely not!

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

Even with Rails, i query by writing directly SQL code, instead of using ActiveRecord.

Code is clean, no more layered abstraction for no purpose.

> 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.

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.

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

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.

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...

It's telling how dominant the (R)DBMS has become, when people can't imagine "database" meaning anything else.

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.

“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.

Reply on news.ycombinator.com