5 ms·

Cool feature, however I'm always worried of anything that encourages developers to push more of the business logic from the code towards database queries. Of c

by emgo 6y ago

Cool feature, however I'm always worried of anything that encourages developers to push more of the business logic from the code towards database queries. Of course you have to balance that out with the cost/time of retrieving a possibly large amount of data for that computation, and computing locally, which is what these SEARCH and CYCLE features aim at preventing. Still, I'd think twice before jumping into using them, to ensure that making the queries more complex does bring enough bang for the buck.

zmmmmm 6y ago
> the cost/time of retrieving a possibly large amount of data for that computation in this case doing it in application space is really problematic because you can't formulate the next query until you see the result of the first - so you will be iterating over and over with sequential queries in your bread or depth first search - really problematic. So while there are many things where it's neutral technically and more a matter of design aesthetic / principle where things go.... in this case it's solving something that just cannot be done sensibly in application space (at least, without large and complex caching logic ...).
catmanjan 6y ago
Is there anything wrong with doing all your work in the database, other than the version control/deployment complications?
- paledot 6y ago
  Scaling. You can autoscale app servers by orders of magnitude, no sweat. Database replicas require much more logistical overhead and provide diminishing returns. The less demand your app places on a database overall, the more scalable it will be. (Of course, running a whole lot of simple queries can be more expensive in the grand scheme of things than one big query, so there's no one-size-fits-all solution to that principle.)
- emgo 6y ago
  One thing I saw at a company I worked for, although it's tangential to technical concerns and more of an anecdote, were political ones. A small team of sysadmins was maintaining a set of very large queries that had grown organically over time, to the point that some of those queries where 20,000 lines. As you know, database queries don't scale as gracefully as code in size, because there's no modules, namespaces, classes, and so on. It's easier to distribute different parts of an application to different people/teams than it is to distributes parts of a database query. Only those sysadmins knew the queries ins and outs and could evolve those queries to the ever-changing business needs. They had an internal monopoly, which gave them a lot of political power over the organization and became a problem over time.
eyelidlessness 6y ago
I’m of the opinion that: 1. If it can be efficiently done in the database, that’s where your business logic actually is. 2. Treating the database as some external foreign thing is generally a bad idea. Your application doesn’t (generally) exist without it. 3. Tools should first-class data stores in general so this distinction is more about federation than network/socket boundaries.
deleted 6y ago
[deleted]

by emgo 6y ago

zmmmmm 6y ago

> the cost/time of retrieving a possibly large amount of data for that computation in this case doing it in application space is really problematic because you can't formulate the next query until you see the result of the first - so you will be iterating over and over with sequential queries in your bread or depth first search - really problematic. So while there are many things where it's neutral technically and more a matter of design aesthetic / principle where things go.... in this case it's solving something that just cannot be done sensibly in application space (at least, without large and complex caching logic ...).

catmanjan 6y ago

Is there anything wrong with doing all your work in the database, other than the version control/deployment complications?

paledot 6y ago
Scaling. You can autoscale app servers by orders of magnitude, no sweat. Database replicas require much more logistical overhead and provide diminishing returns. The less demand your app places on a database overall, the more scalable it will be. (Of course, running a whole lot of simple queries can be more expensive in the grand scheme of things than one big query, so there's no one-size-fits-all solution to that principle.)
emgo 6y ago
One thing I saw at a company I worked for, although it's tangential to technical concerns and more of an anecdote, were political ones. A small team of sysadmins was maintaining a set of very large queries that had grown organically over time, to the point that some of those queries where 20,000 lines. As you know, database queries don't scale as gracefully as code in size, because there's no modules, namespaces, classes, and so on. It's easier to distribute different parts of an application to different people/teams than it is to distributes parts of a database query. Only those sysadmins knew the queries ins and outs and could evolve those queries to the ever-changing business needs. They had an internal monopoly, which gave them a lot of political power over the organization and became a problem over time.

eyelidlessness 6y ago

I’m of the opinion that: 1. If it can be efficiently done in the database, that’s where your business logic actually is. 2. Treating the database as some external foreign thing is generally a bad idea. Your application doesn’t (generally) exist without it. 3. Tools should first-class data stores in general so this distinction is more about federation than network/socket boundaries.

deleted 6y ago

[deleted]