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

131–140 of 144 posts

Re: Databases have failed the web

#131

Post by majewsky »

dpark wrote: post #124
majewsky wrote: post #118

Earlier quoted context omitted.

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.

So? Data in computers is all 0s an 1s, but you don't see anyone complaining about bitly-typed languages. Strong typing refers to the presence of type context wherever a value is used, not to the wire protocol.

Re: Databases have failed the web

#132

Post by geon »

majewsky wrote: post #131
dpark wrote: post #124

Earlier quoted context omitted.

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.

So? Data in computers is all 0s an 1s, but you don't see anyone complaining about bitly-typed languages. Strong typing refers to the presence of type context wherever a value is used, not to the wire protocol.

The data you get out of the database will be untyped.

When the language in the database is typed (SQL) and the language outside is typed too (c#, typescript, etc), it would be nice to keep that type information.

An ORM doesn't count since it is just a bad attemot to work around the inherent problems with SQL as an interface.

Re: Databases have failed the web

#133

Post by anarazel »

geon wrote: post #132
majewsky wrote: post #131

Earlier quoted context omitted.

So? Data in computers is all 0s an 1s, but you don't see anyone complaining about bitly-typed languages. Strong typing refers to the presence of type context wherever a value is used, not to the wire protocol.

The data you get out of the database will be untyped. When the language in the database is typed (SQL) and the language outside is typed too (c#, typescript, etc), it would be nice to keep that type information. An ORM doesn't count since it is just a bad attemot to work around the inherent problems with SQL as an interface.

> The data you get out of the database will be untyped.

Uh, no. Nearly all database access protocols maintain type information for the resultsets returned to the client. That's definitely the case for postgres (cf. RowDescription in https://www.postgresql.org/docs/devel/static/protocol-messag... , accessible to the provided client library via PQftype,cf. https://www.postgresql.org/docs/devel/static/libpq-exec.html... )

There's plenty cases to be made against RDBMs. No need to invent more.

Re: Databases have failed the web

#134

Post by taeric »

dpark wrote: post #125
taeric wrote: post #122

Earlier quoted context omitted.

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

Apologies, I was always arguing for a separation of corporate and customer accounts. My assertion is essentially that all administration of the application is done by corporate users, not application users.

Now, it is not uncommon to actually do this in three parts. A set of users that covers administration. Often made by tools that guarantee corporate level access to these accounts. And then a separate system built on top of them that does the application.

If you have truly "admin" users in the system; then yes, they should be separate from corp. And should be a flaggable part of a normal user's account. Mixing these with who can create the tables that are required for the system to run seems awkward, at best.

Consider, why not support all users being able to just login to the systems that run the application? It is ultimately the same argument, no?

Re: Databases have failed the web

#135

Post by takeda »

josephg wrote: post #94
takeda wrote: post #57

Earlier quoted context omitted.

Yep, I also wanted to add that if you use Mac, or Unix you most likely don't use VT-100. Yes, they all support VT-100, but that's because it became a standard, and essentially any device understands it. For example if you connect to a network switch you know that it will at least support VT-100 so you have a common protocol to communicate with it, and be able to switch to a modern protocol if the device supports it.…

> I feel like the author is a front end developer and just hates the fact that JavaScript in the browser can't communicate with a database server directly. Author here. I hate the fact that here in 2017 we still write login code, again, for every application. I hate the fact that if I want to trigger re-renders, or run workers off database changes all my options suck. > it is also possible that database could provide…

If the problem was as simple you make it, you could write your backend code only once, then re-use it in every project.

Why you are expecting a relational database which has many more use cases than the web programming (and web is not even a primary one) to solve this difficult task for small use cases?

Anyway, there were attempts in solving this and those were called frameworks, which shows that hardly there's a one size fit all. If you use a framework and have complex project you reach a point where the framework will just stay in your way.

> Exactly. It doesn't have to suck - our databases could provide a nice interface to do all this stuff cleanly instead. We just need a resumable event stream, with versions and some other API tweaks and we can do computed views out-of-process of the database, written in whatever language I want.

Not really, a database as name suggests is meant for storing data, it's an already a difficult task by itself (if you want durability and still make it fast). What you need is a backend code that provides this functionality.

> I'm firmly of the opinion that all databases should provide a Samza / Storm / Kafka / etc style event log.

All the technologies you described are stream processors, while they work on data, they operate completely different than a database and they have different use cases. Postgres does have LISTEN/NOTIFY but that's meant more like a side channel for communication.

Perhaps what you need is AQMP?

Re: Databases have failed the web

#136

Post by dragonwriter »

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.

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

How is it extreme; granting or dropping permissions to a particular Role for one user account is certainly not more extreme than dropping or addin a user account in that situation, which is the alternative.

> You also gain the ability to severely lock down destructive permissions to the database behind fairly rigid authentication rules.

Actually, no, you don't, because multiuser RDBMSs (well, most of the commercial ones, plus Postgres, and I'm pretty sure Firebird; MySQL/MariaDB may be weak here, they often seem to be in things that I'd like to say are generally true of RDBMSs) built in security and auth systems already give you this.

Re: Databases have failed the web

#137

Post by dragonwriter »

daliwali wrote: post #29
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…

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…

> Many DBs weren't built to be exposed on the open web.

Most RDBMSs were built to be exposed on untrusted networks, and their built-in security has explicit mechanisms to address this.

Re: Databases have failed the web

#138

Post by dragonwriter »

bluGill wrote: post #78
moron4hire wrote: post #47

Earlier quoted context omitted.

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?!

Note that IT has good reason for the complex change rules: if they make ANY change to the data base, everyone needs to change. The change itself is simple, but in many cases thousands of programs access the database. If taxes don't go out on time because the program that runs once a year at tax time didn't get updated - the best case is the CTO goes to prison, things get worse quickly. When prison is a very real risk…

> Note that IT has good reason for the complex change rules: if they make ANY change to the data base, everyone needs to change.

Only if the DB is used by multiple apps and not designed correctly for that use (e.g., all apps use direct access to base tables rather than app-specific views.)

Unfortunately, this is more common than it should be, but the solution is to stop doing that.

Re: Databases have failed the web

#139

Post by dragonwriter »

lastyearman wrote: post #112
geon wrote: post #62

Earlier quoted context omitted.

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

SQL is the native way query RDBMS.

Re: Databases have failed the web

#140

Post by dragonwriter »

josephg wrote: post #89
thehardsphere wrote: post #15

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

Author here. I think CRUD apps are the most boring example. But think about something like Slack. There's some data and queries, sure - but the app also needs realtime feeds. It needs to have triggers running notification tasks off changes made. There's lots of stuff that need to happen as a result of data changes. Doing all that stuff purely at the application layer is an architectural mess. What you really want is…

Aside from real-time feeds, RDBMSs usually provide the functionality you are discussing, and some can provide real-time change notifications to clients, as well.
Post reply on HN