Hacker News Reader

Comment by mediumdave | Hacker News Reader

> jOOQ is SQL-centric. Your database comes "first".

This approach has always seemed completely backwards to me. Isn't the database simply a mechanism for persisting records/objects whose structure is determined by domain modeling?

To me, it would make about as much to say of a GUI framework "foobarWidgets is GUI-centric. Your UI comes 'first'.", as though the application itself was just an afterthought.

Don't get me wrong - I like SQL, and I happily use relational databases to store objects. I just see the database as a means, not an end.

View on HN

Your data will live for the next 30 years. Your UIs are replaced with every new fad. Do you think it is more important to thoroughly design your database or your client domain model?

Of course, projects are different, and some projects are more user-centric, others are more data-centric, but chances are that you're successful and then you'll regret working with a horrible database schema that you didn't properly design 5 years ago, cause all you cared for were your fancy foobarWidgets that you implemented in a tech that no longer exists...

> Your data will live for the next 30 years. Your UIs are replaced with every new fad. Do you think it is more important to thoroughly design your database or your client domain model?

This cannot be repeated enough. It is an argument I have over and over with people who want to treat the database as a dumb store usually because they do not want to understand databases. Any successful software that stores or generates data will see that data live and used way beyond the original program. The database used will absolutely be the foundation multiple different pieces of software are built on.

10x this! I always get a shiver when I hear people saying "... and it just generates the DB for you...".

DB is what I always start with and it shall stay so.

BTW, is there some jOOQ equivalent for .NET? EntityFramework 7 is all about code-first, which I really don't like.

"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." -- Fred Brooks

At least in the realm of business applications (i.e. not scientific apps, or games, etc.) the most common approach is to keep data (including data dictionaries and db structures) at the center.

In many enterprise contexts, shared databases of very important data are more valuable, more long-lived and more managed than easily replaced applications; applications, often strange and ad hoc ones, are the means applied to the end of keeping databases current and useful for business. Altering old tables in backwards-incompatible ways isn't normally an option.

If you treat a database as "a mechanism for persisting records/objects whose structure is determined by domain modeling" your database will be messy and redundant.

> Isn't the database simply a mechanism for persisting records/objects whose structure is determined by domain modeling?

not at all. you're thinking of a file system.

Reply on news.ycombinator.com