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

111–120 of 144 posts

Re: Databases have failed the web

#111

Post by mmsimanga »

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…

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.

Re: Databases have failed the web

#112

Post by lastyearman »

geon wrote: post #62
dom0 wrote: post #16

Earlier quoted context omitted.

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.

> SQL still works as well as it does today Or... It sucks as badly now as it did back then.

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)

Re: Databases have failed the web

#113

Post by mnm1 »

This rant basically asks: why don't databases do, out of the box, all the custom functionality we program into our web servers?

In other words, why don't databases program the app for me?

What a waste of bandwidth.

Re: Databases have failed the web

#114

Post by foota »

taeric wrote: post #64
fragmede wrote: post #39

Earlier quoted context omitted.

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

You gain making users of your system a first class and distinct part of your application from those that maintain it. Or, would you rather swap a regular user entry into and away from a maintenance role when you hire/fire someone? (Certainly doable, but seems extreme.) You also gain the ability to severely lock down destructive permissions to the database behind fairly rigid authentication rules.

Newest web vulnerability: pivot your way into a job

Re: Databases have failed the web

#115

Post by laumars »

dpark wrote: post #81
laumars wrote: post #46

Earlier quoted context omitted.

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

The only thing new about "NoSQL" is branding. Persistent key-value stores are not new.

Sorry i should have been clearer on my NoSQL point. Yes NoSQL databases may have been around a lot longer than SQL databases but what I'm was talking about specifically was those NoSQL databases that use "webified" formats like JSON as their query language.

It's also worth mentioning that NoSQL encompasses a much broader spectrum of database engines than just key-value stores. Technically any relational database can also be NoSQL so long as it's query language isn't SQL (or even not just SQL if you go by the "not only SQL" definition of NoSQL like some do. Though i find that interpretation too broad personally).

Re: Databases have failed the web

#116

Post by dragonwriter »

carsongross wrote: post #106
dragonwriter wrote: post #98

Earlier quoted context omitted.

> Look, kids. You are going to have to have an execution layer you can trust somewhere, you can't just expose your data store directly to the outside world or you run into an infinite number of security issues The security issues your source points to in new, SQL-like (but not SQL) general query APIs (GraphQL, etc.) are actually already fairly completely addressed in modern relational databases, which are designed fo…

Yeah, no. You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, really hard, we are talking column-level security constraints and worse) or limiting the expressiveness of your query layer. That's the trade off and, in most real world systems, the data stores are wide open to the developer because expressivity wins. Yes, the tec…

> You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, really hard, we are talking column-level security constraints and worse) or limiting the expressiveness of your query layer.

Column and even row-level security constraints are not "really, really hard" to use in modern DBs, and you have to do the analysis of what people should be able to access and effect on that level to build the app, no matter whether you are implementing the constraints through a separate application layer or through the DB itself.

Re: Databases have failed the web

#117

Post by carsongross »

dragonwriter wrote: post #116
carsongross wrote: post #106

Earlier quoted context omitted.

Yeah, no. You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, really hard, we are talking column-level security constraints and worse) or limiting the expressiveness of your query layer. That's the trade off and, in most real world systems, the data stores are wide open to the developer because expressivity wins. Yes, the tec…

> You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, really hard, we are talking column-level security constraints and worse) or limiting the expressiveness of your query layer. Column and even row-level security constraints are not "really, really hard" to use in modern DBs, and you have to do the analysis of what people sh…

A user can only see the salaries of all his direct reports.

Again, there's a reason why almost every web app built in the last twenty years just used user/pass credentials and didn't implement db security beyond that: expressiveness.

But I'm not gonna change your mind on it today. Just think about it for a while.

Re: Databases have failed the web

#118

Post by majewsky »

geon wrote: post #61
daliwali wrote: post #29

Earlier quoted context omitted.

Many DBs weren't built to be exposed on the open web. The web didn't even exist at the time some popular databases were invented, and even after the fact, it's still not the purpose. I would even argue that DBs have overstepped their bounds already with what programming abilities some have built-in. They should be focused on reading and writing structured data efficiently and correctly, not much more than that. Which…

> DBs have overstepped their bounds And they have a stringly typed interface! It sucks! When both the languages inside and outside the database are typed, why should the interface between them not be? It is just unfathomably bad.

Uh, what? How is this stringly-typed: https://www.postgresql.org/docs/9.4/static/datatype.html ? Postgres's type system is actually more sophisticated than any programming language that I know. The problem is that ORM developers are much more serious about interoperability than can be reasonably argued, so you cannot rely on much more than VARCHAR, INTEGER and maybe BOOLEAN.

Re: Databases have failed the web

#119

Post by majewsky »

sbuttgereit wrote: post #48

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

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

That statement applies to the full feature set of modern RDBMSes, not just the security features in particular.

I'm always surprised that I seem to be about the only one (or at least one of very few) on my devops team of ~30 who's comfortable with issuing SELECT statements on the production DB to investigate issues (and sometimes UPDATEs to clean up a mess that users made). And that's not even touching all the crazy stuff (stored procedures, triggers, access permissions), just CRUD (or in this case, INSERT-SELECT-UPDATE-DELETE).

Re: Databases have failed the web

#120

Post by majewsky »

z3t4 wrote: post #103

So you want to implement a new feature, and test it locally, then run tests to make sure you didn't break anything, and when you are done, upload the changes to the production server. This is sane devops, nothing fancy, yet impossible with todays databases. You basically have to manually do the same changes you did in development to the production database, then test if it works on live data in production. Then your…

I for one would not let developers access ny production databases when they clearly don't have any idea how to copy a snapshot into the QA database.
Post reply on HN