Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Databases have failed the web

josephg.com

Post reply on HN
Print view View original

41–50 of 144 posts

Re: Databases have failed the web

#41

Post by jasonkostempski »

okket wrote: post #30
dpark wrote: post #18

Earlier quoted context omitted.

The argument is not that DBs failed the web for scalability, but that they failed the web for features. I don't fully agree but it is an interesting argument. DBs have auth systems already, but we mostly bypass those and reimplement auth in the stateless layer. DBs have programming capabilities but we mostly bypass that and build business logic in the stateless layer. DBs are great at storing and maintaining relation…

> DBs have auth systems already, but we mostly bypass those and reimplement auth in the stateless layer. This is sane and good design. The db auth layer is for db management, not frontend auth (are you seriously advocating this?). > DBs have programming capabilities but we mostly bypass that and build business logic in the stateless layer. This is just (initial) design / programmer laziness. I bet if you start to sca…

> we mostly bypass that and build business logic in the stateless layer.

> This is just (initial) design / programmer laziness.

I disagree, it's just good practice. I've never seen a system evolve towards SQL based business logic, only away from it. SQL is meant for storage, that's it, obviously there needs to be a coding layer to move data in and out of it efficiently but that's where it should end.

Re: Databases have failed the web

#42

Post by vog »

okket wrote: post #30
dpark wrote: post #18

Earlier quoted context omitted.

The argument is not that DBs failed the web for scalability, but that they failed the web for features. I don't fully agree but it is an interesting argument. DBs have auth systems already, but we mostly bypass those and reimplement auth in the stateless layer. DBs have programming capabilities but we mostly bypass that and build business logic in the stateless layer. DBs are great at storing and maintaining relation…

> DBs have auth systems already, but we mostly bypass those and reimplement auth in the stateless layer. This is sane and good design. The db auth layer is for db management, not frontend auth (are you seriously advocating this?). > DBs have programming capabilities but we mostly bypass that and build business logic in the stateless layer. This is just (initial) design / programmer laziness. I bet if you start to sca…

> This is sane and good design. The db auth layer is for db management, not frontend auth (are you seriously advocating this?).

The auth layer of PostgreSQL is very advanced, up to row level security if you need that. [1] It was never intended to be "just for administration", quite the contrary! Moreover, some applications rely exclusively on a central PostgreSQL service rather than a central web service, such as "Artikel23" which is (was?) a CRM whose user management, encryption and security stuff is 100% handled by PostgreSQL.

[1] https://www.postgresql.org/docs/current/static/ddl-rowsecuri...

Re: Databases have failed the web

#43

Post by [deleted] »

fragmede wrote: post #36
agentultra wrote: post #3

I serve many, many millions of rows, collect real-time statistics, push real-time updates, and maintain data integrity and consistency... all from a single database server. If our workloads require it we're prepared to scale out horizontally. I'm really looking forward to PostgreSQL 10's new parallel query features for some of our analytics work. Stack Overflow runs everything across what, 4 MS SQL Servers in total?…

The articles point is that there's a bit more to Stack Overflow than the four database servers it sits on, and because MS SQL is treated as a monolith,a stupid amount of development time, the world over, goes into doing things the database, arguably, could be configured to do itself. I click the accept answer button on my web browser, stack overflow stack reads the cookie my browser presented, does a bunch of logic i…

[deleted]

Re: Databases have failed the web

#44

Post by hive_mind »

dom0 wrote: post #16
pbnjay wrote: post #8

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 consis…

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.

Re: Databases have failed the web

#45

Post by matheweis »

It sounds like the author is unhappy with the fact that web apps have a middle layer that speaks with the database over a terminal emulation.

Ignoring the fact that it happens to make a very nice boundary for an abstraction layer...

> Databases only talk custom binary TCP protocols, not HTTP. Not REST

I take it the author hasn't heard of SCIM?

Re: Databases have failed the web

#46

Post by laumars »

fragmede wrote: post #36
agentultra wrote: post #3

I serve many, many millions of rows, collect real-time statistics, push real-time updates, and maintain data integrity and consistency... all from a single database server. If our workloads require it we're prepared to scale out horizontally. I'm really looking forward to PostgreSQL 10's new parallel query features for some of our analytics work. Stack Overflow runs everything across what, 4 MS SQL Servers in total?…

The articles point is that there's a bit more to Stack Overflow than the four database servers it sits on, and because MS SQL is treated as a monolith,a stupid amount of development time, the world over, goes into doing things the database, arguably, could be configured to do itself. I click the accept answer button on my web browser, stack overflow stack reads the cookie my browser presented, does a bunch of logic i…

> the article's thesis is this is stupid because if the database "just" spoke http, then it could do the majority of that natively, no Ruby/Python/JavaScript/.Net or anything needed.

The issue then becomes scaling. Instead of having half a dozen database nodes you need to keep in sync you could now dozens or hundreds. Possibly even thousands on some applications.

The point of databases is they're meant to be a monolithic repository of persistent data. The point of web servers is that they're supposed to "dumb" and interchangeable. You meant to be able to spin up new instances to scale to demand. This gets greatly more complex if your application is also your database.

It's also not true that databases haven't evolved for the web. We now have NoSQL databases, JSON support in many RDBMS and in-memory databases for caching. Running your web application inside your database is already possibly. There have been posted on HN discussing people doing this. But it's really not practical for much beyond a small scale blog or private (IP whitelisted) API server. ie the kind of thing that the application be hosted on a single node instance and potentially with the DB sharing the same VM too. The moment you need to scale sideways, even just to a small few nodes, it becomes more advantageous to have your database separated from your application servers.

Re: Databases have failed the web

#47

Post by moron4hire »

fragmede wrote: post #39
okket wrote: post #30

Earlier quoted context omitted.

> DBs have auth systems already, but we mostly bypass those and reimplement auth in the stateless layer. This is sane and good design. The db auth layer is for db management, not frontend auth (are you seriously advocating this?). > DBs have programming capabilities but we mostly bypass that and build business logic in the stateless layer. This is just (initial) design / programmer laziness. I bet if you start to sca…

> The db auth layer is for db management, not frontend auth Yes, but why ? The database already has a table of database users, and the different permissions they're allowed. (Well, hopefully your webapp doesn't just do everything as the root DB user with * privs.) Is there that much to be gained from the database having a second table of users that you've created, and then you get to reimplement a bunch of logic in y…

Because traditionally the database was managed by IT, not by engineering. IT came up with the idea that it should take forever to approve changes to the database, so engineering invented ways around their can-don't attitude. Can you imagine any CTO approving a web-based signup page being allowed to change the users to the database?!

Re: Databases have failed the web

#48

Post by sbuttgereit »

The PDP-11 were considered minicomputers, not mainframes, like the IBM System/360. The notion of midrange computing still exists with IBM's iSeries (AS/400), as well mainframes like IBM's zSeries. One could argue that some of these definitions get mushy, but I haven't ever heard disagreements about where the PDPs, AS/400s, and System/360s of the world live in this hierarchy.

This seeming error was an early red flag in this article; having some good facts but having an incomplete picture. While some of the historical observations of what computing was is warranted, this same sort of not having a complete enough picture to draw correct conclusions shows up again in some of the main theses presented.

Consider the statement about the coarseness of permissions. In many modern database systems this simply isn't true. What is true is that is the fully set of security features offered database systems are 1) not widely understood; 2) not bothered with by developers that choose to implement security elsewhere.

Clearly the author spent some time with article and it is well structured, it's simply a matter of the author not having spent as much time getting to the heart of the matter as he/she should have.

Re: Databases have failed the web

#49

Post by AgentK20 »

jasonkostempski wrote: post #41
okket wrote: post #30

Earlier quoted context omitted.

> DBs have auth systems already, but we mostly bypass those and reimplement auth in the stateless layer. This is sane and good design. The db auth layer is for db management, not frontend auth (are you seriously advocating this?). > DBs have programming capabilities but we mostly bypass that and build business logic in the stateless layer. This is just (initial) design / programmer laziness. I bet if you start to sca…

> we mostly bypass that and build business logic in the stateless layer. > This is just (initial) design / programmer laziness. I disagree, it's just good practice. I've never seen a system evolve towards SQL based business logic, only away from it. SQL is meant for storage, that's it, obviously there needs to be a coding layer to move data in and out of it efficiently but that's where it should end.

That's what this article is arguing against. The "good practice" is more precedent than anything. Sure, we can argue that it "adds security" to the mix by adding a separate layer between the user and the actual place where billing info and passwords are stored, but if that front layer gets breached then you're still screwed. From what I understand, the article suggests the reverse of what you're saying. Not necessarily moving the business logic _into SQL_, but what if the DB actually had a very extensible framework and libraries that let you serve HTTP _directly_ from the DB? How would that change reactive websites whose sole "backend" is a SQLJSON+Permissions system? What about if the DB itself supported a psuedo-PHP runtime, or better yet closer to native code?

Granted, I'm not saying it's a good idea. I do see a vast array of benefits, primarily in the sense of scalability, from separating the business logic from the DB, but it's an interesting topic to ponder nonetheless.

Re: Databases have failed the web

#50

Post by omginternets »

okket wrote: post #30
dpark wrote: post #18

Earlier quoted context omitted.

The argument is not that DBs failed the web for scalability, but that they failed the web for features. I don't fully agree but it is an interesting argument. DBs have auth systems already, but we mostly bypass those and reimplement auth in the stateless layer. DBs have programming capabilities but we mostly bypass that and build business logic in the stateless layer. DBs are great at storing and maintaining relation…

> DBs have auth systems already, but we mostly bypass those and reimplement auth in the stateless layer. This is sane and good design. The db auth layer is for db management, not frontend auth (are you seriously advocating this?). > DBs have programming capabilities but we mostly bypass that and build business logic in the stateless layer. This is just (initial) design / programmer laziness. I bet if you start to sca…

I think his argument is that it's "sane and good design" for a problem that now only partially reflects reality on the ground.
Post reply on HN