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

121–130 of 144 posts

Re: Databases have failed the web

#121

Post by dragonwriter »

carsongross wrote: post #117
dragonwriter wrote: post #116

Earlier quoted context omitted.

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

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

With an employee-salary table, that's a fairly simple row-level security rule.

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

I agree that there is a reason, but that's not it; there is a combination of the lack of features in popular (particularly free) databases in the early part of the period (heck, MySQL/MariaDB still doesn't support row-level security), inertia, and lack of database knowledge among web app developers.

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

This is not a new issue for me; I have been thinking about it for quite a long while.

Re: Databases have failed the web

#122

Post by taeric »

dpark wrote: post #107
taeric wrote: post #99

Earlier quoted context omitted.

You probably already have a separate system that is regionally and logically separated from your application to control access to company resources. The argument seems to be that the logical separation is not desired. But that implies that if I were an employee of Google, I should have a specially flagged Google account. And if I were to leave, I would lose that flag. Which means it should probably not be a simple fl…

> You probably already have a separate system that is regionally and logically separated from your application to control access to company resources. The separate system your company's employees are tracked is is also likely not integrated with your app database's auth system. I kind of doubt that the various Postgres/MySQL/Whatever databases at Google have accounts in them for all of Google's employees who might ne…

I wasn't planning on really diving on this. However, two scenarios easily come to mind. Either selling a product to another company, or getting acquired. In either case, it would be nice to not have to merge two identity management systems just because corporate structure changed.

Re: Databases have failed the web

#123

Post by lstroud »

I would argue that databases tried to do too much for too long. If you want a database that has a built in web server, rest apis, security, etc...well Oracle has had that for years. Problem was, that wasn't what people wanted (or wanted to pay for).

The more recent trends have been to decompose the database into something that is great at storing and retrieving data...leaving all of the other stuff to products that do that well.

Re: Databases have failed the web

#124

Post by dpark »

majewsky wrote: post #118
geon wrote: post #61

Earlier quoted context omitted.

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

Query input to SQL is literally a string. Output is also a string. Thus "stringly typed" interface. Yes, DB storage is strongly typed, but the interface is not.

I'm not sure how much an issue this really is, but it's what the GP is talking about.

Re: Databases have failed the web

#125

Post by dpark »

taeric wrote: post #122
dpark wrote: post #107

Earlier quoted context omitted.

> You probably already have a separate system that is regionally and logically separated from your application to control access to company resources. The separate system your company's employees are tracked is is also likely not integrated with your app database's auth system. I kind of doubt that the various Postgres/MySQL/Whatever databases at Google have accounts in them for all of Google's employees who might ne…

I wasn't planning on really diving on this. However, two scenarios easily come to mind. Either selling a product to another company, or getting acquired. In either case, it would be nice to not have to merge two identity management systems just because corporate structure changed.

You're arguing for a separation of customer and admin accounts. These scenarios are both easier if admin and user are rolled together. If administration is tied into your corporate user system, then transferring a product means it's a pain to enable administration in the destination environment.

What you're actually arguing for is keeping app auth separate from corp auth. And that's pretty reasonable, but app admin is app auth, and must move with the app.

More generally, though, anyone buying your app/company will want it integrated with whatever auth they already have anyway, so you can look forward to a big user migration regardless.

Re: Databases have failed the web

#126

Post by agentultra »

josephg wrote: post #96
vog wrote: post #83

Earlier quoted context omitted.

> What about if the DB itself supported a psuedo-PHP runtime, or better yet closer to native code? Note that in PostgreSQL, user defined functions can be written in many languages, including SQL but also Python (very well supported) and PHP (not so well supported, but doable).

Post author here. I actually think it would be much cleaner to support an event log API and run this stuff out-of-process. My database shouldn't have to support the language-de-jour, and I don't want my react rendering process slowing down my database servers. You can totally decouple this stuff with a clean kafka-like eventlog API, but postgres doesn't provide one.

Yes it does. There many ways you can do it too.

See the docs for NOTIFY/LISTEN for an easy built in solution. Use a trigger to write to a log table for durability.

And the time travel functions.

All with the powerful query engine.

There are projects to stream all operations straight into Kafka.

The nice thing about Postgres is that it's also extensible. PipelineDB, Citus, etc.

Re: Databases have failed the web

#127

Post by YCode »

geon wrote: post #84
dasil003 wrote: post #70

Earlier quoted context omitted.

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

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.

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

Re: Databases have failed the web

#128

Post by z3t4 »

majewsky wrote: post #120
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.

May I ask how much it would cost, in total man hours, to for example change the name of a field ? For example make "name" into firstName and lastName.

Re: Databases have failed the web

#129

Post by throwanem »

WrtCdEvrydy wrote: post #109
tomc1985 wrote: post #86

Earlier quoted context omitted.

I know, they're so scary aren't they?

No, in terms of Return on Investment, it just isn't worth it for me. Noone cares if a large query takes 10 seconds or 11 seconds with ActiveRecord enough to blow developer time on it.

No one cares until they do, because the dataset's grown nontrivial and the crap 10s query Active Record generates is now a crap 120s query and one of the server, the client, or the user times out before it finishes.

Re: Databases have failed the web

#130

Post by majewsky »

z3t4 wrote: post #128
majewsky wrote: post #120

Earlier quoted context omitted.

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.

May I ask how much it would cost, in total man hours, to for example change the name of a field ? For example make "name" into firstName and lastName.

Anywhere between maybe 1-2 man hours and multiple man months, depending on how nice the data is right now, and how accurate it need to be split. The optimal case would be the application already enforcing values to look like e.g. "last, first", so that the migration can happen via a simple regex.
Post reply on HN