I think databases have been so wildly successful because they were actually based on some reasonable research about data access models and set theory. I encourage anyone who wants to criticize the relational model to start with E.F. Codd's "A relational model of data for large shared data banks".
Databases have failed the web
11–20 of 144 posts
Re: Databases have failed the web
#12I 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?…
because SELECT statements don't spawn UDP connections and AJAX service workers, because that is what a dataBASE is supposed to do.
you're all idiots.
Re: Databases have failed the web
#13To be honest, this article seems pretty insubstantial. To the best of my ability to discern, the only concrete complaint is that access control is too coarse on modern databases, although it's not really specified in what way this is true.
Agree. Postgres now has row-level security and one could always apply custom access control using functions/triggers.
Re: Databases have failed the web
#14It isn't that "everybody emulates the VT-100 for some reason" but that the VT-100 was the first terminal to support the ANSI standard for control codes and that that standard has been evolving ever since.
Real Programmers emulate a VT-52.
Re: Databases have failed the web
#15The conceit of this article seems to be that all web applications are merely CRUD apps that do nothing but talk to the database, thus databses are "failing the web" for... not being more than just a database.
I see a number of problems with this:
1. Not every web app is merely CRUD. Some of us work on apps that do quite a bit more than CRUD, and the CRUD part is relatively small and boring.
2. There's very little respect here for the idea that good utilities should do one thing and do that thing very well. Lots of people need relational databases. Not everybody needs a relational database that can automagically filter out XSS attacks and serve HTTP responses.
Re: Databases have failed the web
#16I 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.
Re: Databases have failed the web
#17> Access control on modern databases is too course. You want to whitelist which queries a user is allowed to make and you want fine-grained permissions around updates
Only allow direct access to stored procs, not queries. Or restrict access to specific views and use rules (https://www.postgresql.org/docs/current/static/sql-createrul...) but intuitively that seems more dangerous (with CTE, I believe SQL is turing-complete) and completely unnecessary.
> Databases only talk custom binary TCP protocols, not HTTP. Not REST. Not websockets. So you need something to translate between how the server works and how the browser works.
> You want to write complex logic for user actions
https://www.postgresql.org/docs/current/static/plpgsql-struc...
> with custom on-save triggers
https://www.postgresql.org/docs/current/static/plpgsql-trigg...
> and data validation logic.
https://www.postgresql.org/docs/current/static/ddl-constrain...
Re: Databases have failed the web
#18I 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 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 relations and relationships but much of the other functionality is little-used.
Re: Databases have failed the web
#19[deleted]
Re: Databases have failed the web
#20I 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…
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".