3 ms·

>You said "As much logic that can be pushed to the database as possible" and that's simply not true. The normal, mainstream way (like it or not) is to use the d

>You said "As much logic that can be pushed to the database as possible" and that's simply not true. The normal, mainstream way (like it or not) is to use the database as a dumb store and have the business logic in the application layer. False. What I said is true. As much as possible is 100% true. There are some things that have to live in the business layer. But as much as possible should be pushed to the database. All the "business layer" does is build the correct query. What you're describing is multiple queries The web application has to fetch data, do "business logic" then fetch or update data again. That is both slow and inefficient, but sometimes necessary. As much as possible the web application needs to build the query and do everything in a single IO call. The round trip time and even simply initializing multiple queries on the database side is magnitudes slower then one query that does the full operation. Business logic should be extremely thin. This idea of a dumbstore is highly misguided. No framework works like this. The database is the workhorse of the basic web application, the application layer is suppose to be the thinnest layer. Your ORM, query builder or SQL code is where most of the logic real should lie. >None of that is business logic. It's implementation details at best. False again. The basic SQL query is this: SELECT <COLUMNS> FROM <TABLE> that is list retrieval at an API level and Not just implementation details. A key value store looks like this: VALUE = MAP[KEY] Understand? There is no equivalent of key value fetching in SQL, you basically have to filter that list with SELECT * FROM TABLE WHERE id = ... You can imitate a key value store both at the implementation level and at the API level if you use a hash index on a unique id like in the example query I just mentioned, but that is not the primary mode of the SQL api. I don't think you get it.

prmph 3y ago
> False. What I said is true. As much as possible is 100% true. There are some things that have to live in the business layer. But as much as possible should be pushed to the database. All the "business layer" does is build the correct query. I think you are wrong, the other commenter is correct. In all my years of engineering, I rarely see a lot of business logic in the database. Note that we are talking about what the situation _is_, not what it should be. It is an eternal debate as to whether it is better to push as much login into the Db as possible. My own view is that you should use the right tool for the job. Databases, excel at, well, managing data. Regular languages excel at logic. > Business logic should be extremely thin. I'm leading a team building a front end to statistical engines, storing metadata in the Db. Are you suggesting we should implement the higher level statistical functions in the Db?
- corethree 3y ago
  Your talking about the multitudes of architectures that stem from the core model. I'm talking about the core model. Which is crud. The core model of a typical website is mainly updates to central state with little compute. Think nodejs server paired with a typical SQL database. The very reason nodejs exists is based on this core assumption of web: low compute and non blocking high io workflows. You're talking about heavy compute... then that deviates from the core model. With heavy compute it turns more into a queue with workers. That is not the core architecture of the web. It's more of popular and important system that exists in conjunction with the core. That is what your statistical function implies. If your stats function is simple and trivial, then you can indeed possibly achieve orders of magnitude of speed up if you offload that trivial calculation to the database.
lmm 3y ago
> Business logic should be extremely thin. > This idea of a dumbstore is highly misguided. No framework works like this. The database is the workhorse of the basic web application, the application layer is suppose to be the thinnest layer. Your ORM, query builder or SQL code is where most of the logic real should lie. Like it or not, all the big mainstream web frameworks are oriented towards having the business logic in the application layer. Again, look at what kind of querying the ORM supports. > The basic SQL query is this: SELECT <COLUMNS> FROM <TABLE> that is list retrieval at an API level and Not just implementation details. A key value store looks like this: VALUE = MAP[KEY] Understand? > There is no equivalent of key value fetching in SQL, you basically have to filter that list with SELECT * FROM TABLE WHERE id = ... If you look at the ORM APIs and the way mainstream web frameworks use them, fetching an object by primary key is very much the primary supported way of using them. MySQL even added the option of querying via the memcached protocol after their benchmarks showed that for typical web services it was taking 3x as long to parse the SQL as actually running the query.
- corethree 3y ago
  I'm an expert on big mainstream web frameworks. It's not about what I like. It's about you being wrong. Orms are apis that are one to one with SQL queries. They do not turn SQL database into key value stores. It's not even a surface level change. On the surface the orm API is designed at it's core to allow you to construct a SQL query in the form of an oop object. And the SQL query is clearly not a key value store API. Ask anyone. The primary usage of a SQL database is definitely not primary key queries to fetch one row at a time. Not at all not even close. The primary key thing is just a unique Id that orms could use for a shortcut method that returns a singular row. But make no mistake primarily orms return lists and you have to filter those lists. SQL is designed for relationships and sets. The mathematics behind it is all about creating a new set as a composition of other sets. Tables are sets, joins are relationships. The composition of tables results in a new table or aka set. >If you look at the ORM APIs and the way mainstream web frameworks use them, fetching an object by primary key is very much the primary supported way of using them. MySQL even added the option of querying via the memcached protocol after their benchmarks showed that for typical web services it was taking 3x as long to parse the SQL as actually running the query. It's one way of using SQL. It is not the primary way. You are utterly wrong. In your where clause "Id = 2" that would be what you're describing. The problem here is SQL obviously supports more complex where clauses. "Id > 2" "Id != 4" both of which will return lists and sets. And all orms should support features related to list filtering. Don't understand how memcache lends any weight to your point. What does parsing and caching queries have to do with your wrong point of sql being a key value store. You can cache parsing in things unrelated to key value stores. Again I don't think you get it.

prmph 3y ago

> False. What I said is true. As much as possible is 100% true. There are some things that have to live in the business layer. But as much as possible should be pushed to the database. All the "business layer" does is build the correct query. I think you are wrong, the other commenter is correct. In all my years of engineering, I rarely see a lot of business logic in the database. Note that we are talking about what the situation _is_, not what it should be. It is an eternal debate as to whether it is better to push as much login into the Db as possible. My own view is that you should use the right tool for the job. Databases, excel at, well, managing data. Regular languages excel at logic. > Business logic should be extremely thin. I'm leading a team building a front end to statistical engines, storing metadata in the Db. Are you suggesting we should implement the higher level statistical functions in the Db?

corethree 3y ago
Your talking about the multitudes of architectures that stem from the core model. I'm talking about the core model. Which is crud. The core model of a typical website is mainly updates to central state with little compute. Think nodejs server paired with a typical SQL database. The very reason nodejs exists is based on this core assumption of web: low compute and non blocking high io workflows. You're talking about heavy compute... then that deviates from the core model. With heavy compute it turns more into a queue with workers. That is not the core architecture of the web. It's more of popular and important system that exists in conjunction with the core. That is what your statistical function implies. If your stats function is simple and trivial, then you can indeed possibly achieve orders of magnitude of speed up if you offload that trivial calculation to the database.

lmm 3y ago

> Business logic should be extremely thin. > This idea of a dumbstore is highly misguided. No framework works like this. The database is the workhorse of the basic web application, the application layer is suppose to be the thinnest layer. Your ORM, query builder or SQL code is where most of the logic real should lie. Like it or not, all the big mainstream web frameworks are oriented towards having the business logic in the application layer. Again, look at what kind of querying the ORM supports. > The basic SQL query is this: SELECT <COLUMNS> FROM <TABLE> that is list retrieval at an API level and Not just implementation details. A key value store looks like this: VALUE = MAP[KEY] Understand? > There is no equivalent of key value fetching in SQL, you basically have to filter that list with SELECT * FROM TABLE WHERE id = ... If you look at the ORM APIs and the way mainstream web frameworks use them, fetching an object by primary key is very much the primary supported way of using them. MySQL even added the option of querying via the memcached protocol after their benchmarks showed that for typical web services it was taking 3x as long to parse the SQL as actually running the query.

corethree 3y ago
I'm an expert on big mainstream web frameworks. It's not about what I like. It's about you being wrong. Orms are apis that are one to one with SQL queries. They do not turn SQL database into key value stores. It's not even a surface level change. On the surface the orm API is designed at it's core to allow you to construct a SQL query in the form of an oop object. And the SQL query is clearly not a key value store API. Ask anyone. The primary usage of a SQL database is definitely not primary key queries to fetch one row at a time. Not at all not even close. The primary key thing is just a unique Id that orms could use for a shortcut method that returns a singular row. But make no mistake primarily orms return lists and you have to filter those lists. SQL is designed for relationships and sets. The mathematics behind it is all about creating a new set as a composition of other sets. Tables are sets, joins are relationships. The composition of tables results in a new table or aka set. >If you look at the ORM APIs and the way mainstream web frameworks use them, fetching an object by primary key is very much the primary supported way of using them. MySQL even added the option of querying via the memcached protocol after their benchmarks showed that for typical web services it was taking 3x as long to parse the SQL as actually running the query. It's one way of using SQL. It is not the primary way. You are utterly wrong. In your where clause "Id = 2" that would be what you're describing. The problem here is SQL obviously supports more complex where clauses. "Id > 2" "Id != 4" both of which will return lists and sets. And all orms should support features related to list filtering. Don't understand how memcache lends any weight to your point. What does parsing and caching queries have to do with your wrong point of sql being a key value store. You can cache parsing in things unrelated to key value stores. Again I don't think you get it.