3 ms·

What does "business logic" mean to you? According to the Wikipedia definition [1], I find it very difficult to imagine SQL that does not contain business logic.

by taffer 6y ago

What does "business logic" mean to you? According to the Wikipedia definition [1], I find it very difficult to imagine SQL that does not contain business logic. [1] "business logic or domain logic is the part of the program that encodes the real-world business rules that determine how data can be created, displayed, stored, and changed.", https://en.wikipedia.org/wiki/Business_logic https://en.wikipedia.org/wiki/Business_logic

UK-Al05 6y ago
Business Logic is calculating tax, working out price, adding something to a bag, populating an order object with infomation according to some rules. Business logic isn't pulling data from database, how to map an object to a table, or the specific SQL query to grab some data. Those are technical details. SQL should just be pulling, saving and querying from the store without much maniplation. Not changing the data. It's the rules that a business stakeholder might be interested in creating. When you start putting the tax calculation rules into the stored proc, thats where the problems begin. If you create a CTE to pull the information required to perform the calulation then return that info without doing the calculation thats fine.
- monadic2 6y ago
  How about a state machine encoding cart state? There are many advantages to encoding state changes in sql, but the database logic isn't strictly tied to the specifics of the cart logic. However trying to decouple these domains fully will create many more problems. There's plenty of fuzzy problems like this that interleave the technical and business. I fail to see how ANY part of a project would fail to be of interest to a stakeholder. They don't much care whether a failure emanated from code you have labeled of interest to them or not. You certainly can't make much money without supporting the business logic with—apparently—non-business storage. Even if you can patch up the leaks in this semantic distinction between these two domains the use of such a distinction is not clear in any general sense. These abstractions are to help the coder reason about complex systems and they don't always work. You then need to invent better abstractions.
- taffer 6y ago
  Let's assume there is a business requirement that an order belongs to a customer. By definition, this is business logic. If you implement this requirement by creating a foreign key constraint, then you have added business logic to the database. If there is a business requirement to calculate the sum of all wages in a department, and you do this via an aggregation in SQL, then you have processed business logic in the database. If you are not allowed to do this kind of things, then what is left? Do you interact with your database as if it were just a bunch of VSAM files?
  - UK-Al05 6y ago
    Tbh a lot of NoSQL databases don't use foreign key constraints. If you have a SQL system with messaging and eventual consistency you have to turn them off anyway. So in a lot of ways, yes people use databases like they're just persistent memory with indexes.

by taffer 6y ago

UK-Al05 6y ago

Business Logic is calculating tax, working out price, adding something to a bag, populating an order object with infomation according to some rules. Business logic isn't pulling data from database, how to map an object to a table, or the specific SQL query to grab some data. Those are technical details. SQL should just be pulling, saving and querying from the store without much maniplation. Not changing the data. It's the rules that a business stakeholder might be interested in creating. When you start putting the tax calculation rules into the stored proc, thats where the problems begin. If you create a CTE to pull the information required to perform the calulation then return that info without doing the calculation thats fine.

monadic2 6y ago
How about a state machine encoding cart state? There are many advantages to encoding state changes in sql, but the database logic isn't strictly tied to the specifics of the cart logic. However trying to decouple these domains fully will create many more problems. There's plenty of fuzzy problems like this that interleave the technical and business. I fail to see how ANY part of a project would fail to be of interest to a stakeholder. They don't much care whether a failure emanated from code you have labeled of interest to them or not. You certainly can't make much money without supporting the business logic with—apparently—non-business storage. Even if you can patch up the leaks in this semantic distinction between these two domains the use of such a distinction is not clear in any general sense. These abstractions are to help the coder reason about complex systems and they don't always work. You then need to invent better abstractions.
taffer 6y ago
Let's assume there is a business requirement that an order belongs to a customer. By definition, this is business logic. If you implement this requirement by creating a foreign key constraint, then you have added business logic to the database. If there is a business requirement to calculate the sum of all wages in a department, and you do this via an aggregation in SQL, then you have processed business logic in the database. If you are not allowed to do this kind of things, then what is left? Do you interact with your database as if it were just a bunch of VSAM files?
- UK-Al05 6y ago
  Tbh a lot of NoSQL databases don't use foreign key constraints. If you have a SQL system with messaging and eventual consistency you have to turn them off anyway. So in a lot of ways, yes people use databases like they're just persistent memory with indexes.