6 ms·
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.
by dpark 10y ago
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.
- WrtCdEvrydy 10y agoMaybe if there was better support at the connection layer, this might be better. If ActiveRecord (Rails) allowed you to pass a free-form ruby function and built a procedure and executed it in SQL, I'd be all for it, but I'm not writing a one-off procedure and mantaining it.
- tomc1985 10y agoWhat is there to maintain? It's not hard to directly emit SQL to ActiveRecord
- WrtCdEvrydy 10y agoI'm not writing a one-off procedure in RAW SQL. If ActiveRecord could turn functions into SQL equivalents, it would be awesome.
- tomc1985 10y agoI know, they're so scary aren't they?
- WrtCdEvrydy 10y agoNo, 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.
- throwanem 10y agoNo 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.
- vog 10y agoThe PostgrREST project is an interesting approach so fill this gap: https://postgrest.com/ https://postgrest.com/
- deleted 10y ago[deleted]
- zitterbewegung 10y agoIt sounds like you would like to look at something like postgrest. See https://github.com/begriffs/postgrest https://github.com/begriffs/postgrest
- deleted 10y ago[deleted]
- daliwali 10y agoMany 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 database to use should depend on access patterns and structural requirements. Let the application logic be handled at a higher layer instead of mixing responsibilities everywhere.
- geon 10y ago> 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.
- majewsky 10y agoUh, what? How is this stringly-typed: https://www.postgresql.org/docs/9.4/static/datatype.html 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.
- dpark 10y agoQuery 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.
- majewsky 10y agoSo? 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.
- okket 10y ago> 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 scale up, you will think a lot about moving your business logic further to the real data for safety and for performance reasons. This is the point when you realise that db systems are very different and switching from one to another is not that easy...
- fragmede 10y ago> 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 your app server on top of the database so that you have... users and permissions?
- moron4hire 10y agoBecause 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?!
- mixmastamyk 10y agoIf it only adds restricted users is that a big problem?
- moron4hire 10y agoThe problem is not an issue of technology.