4 ms·

I'm not horrified, as I've had similar thoughts to yours lately. I do think you might get a better response if you could extrapolate on your reasons for moving

by ebcode 7y ago

I'm not horrified, as I've had similar thoughts to yours lately. I do think you might get a better response if you could extrapolate on your reasons for moving the logic into the database. Maybe a blog post? Your argument that a schema w/ keys is already "business logic" could be refuted with the stance that the database is actually the "business model", and the logic is in how the rows and columns are updated, which takes place (and should) in the "application", not the "storage mechanism". What I imagine is that because SQL was not originally conceived to be a turing complete language, the possibility of having your business logic in the database was simply not there. The possibility now exists, and I've run into projects where stored procedures do a lot of heavy lifting, but I've never seen an example where stored procedures do all of it. After all, you wouldn't write your UI w/ a stored procedure.

taffer 7y ago
> the logic is in how the rows and columns are updated, which takes place (and should) in the "application", not the "storage mechanism". Business logic is any logic that exists to encode business requirements[1], everything else is just plumbing. If there is a requirement that each product must have a category, then you need business logic to enforce this. If there is a requirement that a price must not be negative, then that is business logic. Where to put this logic? I would put it in the database. > What I imagine is that because SQL was not originally conceived to be a turing complete language, the possibility of having your business logic in the database was simply not there. SQL is based on relational algebra, which is based on first order logic. So it is perfect for business logic [2] and it rarely takes a turing complete language to implement business requirements. [1] https://en.wikipedia.org/wiki/Business_logic https://en.wikipedia.org/wiki/Business_logic [2] https://www.vertabelo.com/blog/notes-from-the-lab/business-logic-in-the-database-yes-or-no-it-depends https://www.vertabelo.com/blog/notes-from-the-lab/business-l...

by ebcode 7y ago

taffer 7y ago

> the logic is in how the rows and columns are updated, which takes place (and should) in the "application", not the "storage mechanism". Business logic is any logic that exists to encode business requirements[1], everything else is just plumbing. If there is a requirement that each product must have a category, then you need business logic to enforce this. If there is a requirement that a price must not be negative, then that is business logic. Where to put this logic? I would put it in the database. > What I imagine is that because SQL was not originally conceived to be a turing complete language, the possibility of having your business logic in the database was simply not there. SQL is based on relational algebra, which is based on first order logic. So it is perfect for business logic [2] and it rarely takes a turing complete language to implement business requirements. [1] https://en.wikipedia.org/wiki/Business_logic https://en.wikipedia.org/wiki/Business_logic [2] https://www.vertabelo.com/blog/notes-from-the-lab/business-logic-in-the-database-yes-or-no-it-depends https://www.vertabelo.com/blog/notes-from-the-lab/business-l...