Hacker News Reader

Comment by pbnjay | Hacker News Reader

I really disagree with this - separation of concerns is incredibly important. Why does the database server need to do everything my application server does now?

I don't want to have to know about how my database works internally just to implement a new feature in my application. I don't want to worry about a junior dev corrupting data while building a login page.

My "simple old-school" database is reliable and consistent BECAUSE it's been tested for years. My application server is not because it's solving a new problem (And that's OK, I won't lose customer data if someone can't login).

View on HN

Fully agreed. The observation that SQL still works as well as it does today as it did in the 70s suggests that it's a good and valueable abstraction.

Lindy Effect.

I can't tell if you're describing or disputing the comment you replied to.

Are you saying SQL survived only because people have used it for so long and therefore its sustained use isn't an indicator of value?

If you read up on what Taleb writes about Lindy Effect, you should be able to understand.

OP said that it's probably good because it has lasted so long. I would agree.

> SQL still works as well as it does today

Or... It sucks as badly now as it did back then.

Well, no. There were a zillion databases competing and SQL is what survived. The NoSQL movement has created a bunch of useful DBs for specific scaling workloads, and of course there are graph DBs and other special purpose DBs, but SQL still dominates, and with good reason: it's the right balance of performance, flexibility, structure and integrity that makes it an excellent hedge for the early phases of application development when you're not yet sure what exactly the workload is going to look like.

HTML and CSS "won" on the web. No one in their right mind would call them good or even suitable for their main use case.

Of course they are. Most things on the web are documents. The fact that it is abused for SPAs means that yes they are contorted and abused, but that is inevitable because Gall's Law.

It's easy sit in an armchair and point out all the warts on specific tech, but if you were to build a better solution to broad technology segments like this, and magically get adoption, you'd find that you only understood 5% of the application space, and your better version is subject to whole swaths of criticism that you didn't anticipate. Better to find one small/simple thing you can do well and build from there.

What's more suitable for their main use case? What is their main use case?

Every time I have to glue together pieces of SQL at runtime I have to agree. It seems crazy to me that there is no "native" way to query relational DB's (yes, there are some SQL factories for certain languages)

SQL is the native way query RDBMS.

Yes, and the fact that a relational model is such a convenient way to represent lots of data problems means that even if SQL disappeared, the concept and usefulness of a relational database would long outlive it.

Came here to basically say this much. Part of me feels already that databases are already too hugely complex. The "do one thing, well" part of me wants one application for data storage, and then middleware for relationship enforcement, stored procedures, etc. That's likely too pedantic for most but I really see wanting your data layer to be your application layer as a silly throwback.

Also isn't this a similar idea to what FileMaker Bento did?

I'd argue that there is some merit into combining those things, or at least changing where the separation happens.

There might be performance improvements and better abstractions from moving what is traditionally known as "application code" into a place where it has better, more direct, access to the data.

I'm not saying that we should be throwing out SQL and starting over, but if there are massive gains to be had by letting the database do MORE (or redefining what the database actually is, maybe "merging" it with the application code so that this new "thing" has knowledge of both how the data is stored as well as how it will be processed), why not explore those?

Honestly I'm being vague because I have no real idea what I'm talking about here, but if you look at the past, you see this in many other areas. First the FPU joined the CPU, then the GPU joined the CPU, then phones happened and you get the SOC where everything is in the "CPU".

Stored Procedures have been around for a long time, so it's very easy to put some business logic closer to your database without resorting to the level of integration suggested by the post.

yes but in my experience even though they exist, many applications are written in an outside environment, in order to take advantage of software engineering facilities that are not available "in the DB". This competes with the idea of merging the app into the DB and is why the split is common place.

I work in BI. There is a joke that the most utilized BI tool is MS Excel. Organizations pay millions for tools like Tableau and Cognos. The stumbling block to successful BI is the amount of time it takes to create tables, write ETL and make tables available to end users. It takes so long users just export data from operational systems and do their own reports.

I see where OP is coming from. The data resides in database but there is no "easy" may to make it available to end users. So everyone does their own thing anyway. Yes I appreciate a well curated database but something is amiss.

Reply on news.ycombinator.com