4 ms·

I rather have data separated from operations done on data. I am very happy since I don't have to deal anymore with stored procedures.

littlestymaar 3y ago
Honestly, the main issue I have with stored procedures is mostly the tooling that is stuck in the 80s… For many things, having an “application server” running code that is merely chaining SQL queries (often hiding them with an ORM and performing way too much queries, destroying performance in the process) is not a particularly good idea… The main reason we do it is because we can have a proper debugger, write unit tests, have an IDE, etc. but there's no fundamental why stored procedures could not give the same developer experience, except that RDBMS vendors don't give a sh*t.
- danpalmer 3y ago
  This is true, I'd love to see a truly modern application development process built entirely around hosting in a database. However, one other concern is that scaling out databases is much harder than scaling out stateless processing layers, and therefore at scale there's a huge benefit to separating as much out of the storage layer as possible.
  - refset 3y ago
    One such effort: https://github.com/omnigres/omnigres https://github.com/omnigres/omnigres
    - dfee 3y ago
      Horrifying, yet brilliant.
    - danpalmer 3y ago
      Yeah this is sort of what I'm thinking of, thanks!
  - gtirloni 3y ago
    Something like CouchDB "applications"? [0] 0 - https://docs.couchdb.com/en/latest/ddocs/index.html https://docs.couchdb.com/en/latest/ddocs/index.html
  - zokier 3y ago
    In addition to sibling comments, there is also https://postgrest.org/ https://postgrest.org/
- zokier 3y ago
  There is the operational aspect that managing stateless components is usually much more pleasant from ops point of view. And DMBS is the very opposite of stateless. So in many cases it is preferrable to extract as much as possible any computational etc parts of an application from DBMS to separate stateless components that can then be scaled/updated/maintained/etc independently.
  - metricspaces 3y ago
    This is an interesting point but imo ignores the facilities afforded by an RDBMS and possibly even misunderstands the notion of fully hosting applications on a RDBMS. Some sort of check pointing is inevitable for recoverable state-less systems (that naturally react to a stream of data/queries) and that ultimately is delegated to either a streaming/messaging (e.g. kafka) or a database (of some sort). Components of an application hosted in a RDBMS are tables, indexes, views, and code. The code is stateless — they’re just functions. Application state is in tables. Replication is supposed to handle your more hairy operational concerns. What’s the problem?
    - zokier 3y ago
      > Replication is supposed to handle your more hairy operational concerns. What’s the problem? Replication is slow, and requires each node to have lot of resources, and generally prefers nodes to be realtively homogenous. But for non-trivial applications replicating the whole application (or some shard of it) to all nodes is simply impractical, and it is useful to be able to scale and adjust different parts of system independently. For example on AWS Lambda you can scale out up to 1000 new instances per 10 seconds (and scale in at similar rate). Can you imagine any DMBS replication working very effectively at such circumstances?

littlestymaar 3y ago

Honestly, the main issue I have with stored procedures is mostly the tooling that is stuck in the 80s… For many things, having an “application server” running code that is merely chaining SQL queries (often hiding them with an ORM and performing way too much queries, destroying performance in the process) is not a particularly good idea… The main reason we do it is because we can have a proper debugger, write unit tests, have an IDE, etc. but there's no fundamental why stored procedures could not give the same developer experience, except that RDBMS vendors don't give a sh*t.

danpalmer 3y ago
This is true, I'd love to see a truly modern application development process built entirely around hosting in a database. However, one other concern is that scaling out databases is much harder than scaling out stateless processing layers, and therefore at scale there's a huge benefit to separating as much out of the storage layer as possible.
- refset 3y ago
  One such effort: https://github.com/omnigres/omnigres https://github.com/omnigres/omnigres
  - dfee 3y ago
    Horrifying, yet brilliant.
  - danpalmer 3y ago
    Yeah this is sort of what I'm thinking of, thanks!
- gtirloni 3y ago
  Something like CouchDB "applications"? [0] 0 - https://docs.couchdb.com/en/latest/ddocs/index.html https://docs.couchdb.com/en/latest/ddocs/index.html
- zokier 3y ago
  In addition to sibling comments, there is also https://postgrest.org/ https://postgrest.org/
zokier 3y ago
There is the operational aspect that managing stateless components is usually much more pleasant from ops point of view. And DMBS is the very opposite of stateless. So in many cases it is preferrable to extract as much as possible any computational etc parts of an application from DBMS to separate stateless components that can then be scaled/updated/maintained/etc independently.
- metricspaces 3y ago
  This is an interesting point but imo ignores the facilities afforded by an RDBMS and possibly even misunderstands the notion of fully hosting applications on a RDBMS. Some sort of check pointing is inevitable for recoverable state-less systems (that naturally react to a stream of data/queries) and that ultimately is delegated to either a streaming/messaging (e.g. kafka) or a database (of some sort). Components of an application hosted in a RDBMS are tables, indexes, views, and code. The code is stateless — they’re just functions. Application state is in tables. Replication is supposed to handle your more hairy operational concerns. What’s the problem?
  - zokier 3y ago
    > Replication is supposed to handle your more hairy operational concerns. What’s the problem? Replication is slow, and requires each node to have lot of resources, and generally prefers nodes to be realtively homogenous. But for non-trivial applications replicating the whole application (or some shard of it) to all nodes is simply impractical, and it is useful to be able to scale and adjust different parts of system independently. For example on AWS Lambda you can scale out up to 1000 new instances per 10 seconds (and scale in at similar rate). Can you imagine any DMBS replication working very effectively at such circumstances?