2 ms·

No, stored procedures is not a part of business logic. Read books of Robert Martin and Martin Fowler, they will explain it for you.

fdr 14y ago
Procedures are procedures regardless of where they are written. In many aspects it can be mechanically more difficult to deal with SQL UDFs but that is a usability weakness that just needs some more treatment rather than anything particularly fundamental, I feel. There are three common reasons I write UDFs: * The SQL type system and dependency tracking are deemed helpful. This applies only to 'LANGUAGE SQL' functions, which are just regular queries. Unlike dynamically generated SQL from the application, type checks and dependency tracking on other SQL objects can be employed. This is hard to address in any tooling without having a complete copy of the catalogs (and many databases are not as self-hosted complete as Postgres' catalogs, so sometimes that may not be enough...) and semantic analyzer. * Diverse language and/or library access. If there is a series of obscure rules to hold simple invariants locked into exactly one application's libraries, it makes it pretty much impossible to use any other library. This can be addressed, but it's often expensive to do so. * Performance, in rare cases where network round trip dominates execution time and I need more than one plain SQL statement; this is only the case for the integrated 'procedural' languages. One could accomplish something similar by running the application's code closer to the machine, and I think that'd be better, actually, but requires some orchestration.
mryan 14y ago
I think the flood of replies disagreeing with you suggest you might want to rethink that assumption. Another reply to your post said you are making a 'religious argument' - I think there is some truth in that. If you had said "in my experience, shared procs are not a good place to store business logic", that would have been your opinion, and no-one could argue with you. But you stated, as fact, that "business logic should be written in code, not in data and not in the database". This is not objectively true for all companies, and can be easily disproved. And was disproved, by all the people who said this assumption is incorrect. Throwing around the names of authors does nothing to help your case (useless "appeal to authority"). I have read some of Robert Martin's work (but none of Martin Fowler's) and still think storing business logic in database rules can be a very good idea.
- EugeneOZ 14y ago
  "And was disproved" - lol. It was just disputed, but not disproved. I don't care about flood of some anonymous on HN, I more care about articles and books, written by really experienced authors.

fdr 14y ago

Procedures are procedures regardless of where they are written. In many aspects it can be mechanically more difficult to deal with SQL UDFs but that is a usability weakness that just needs some more treatment rather than anything particularly fundamental, I feel. There are three common reasons I write UDFs: * The SQL type system and dependency tracking are deemed helpful. This applies only to 'LANGUAGE SQL' functions, which are just regular queries. Unlike dynamically generated SQL from the application, type checks and dependency tracking on other SQL objects can be employed. This is hard to address in any tooling without having a complete copy of the catalogs (and many databases are not as self-hosted complete as Postgres' catalogs, so sometimes that may not be enough...) and semantic analyzer. * Diverse language and/or library access. If there is a series of obscure rules to hold simple invariants locked into exactly one application's libraries, it makes it pretty much impossible to use any other library. This can be addressed, but it's often expensive to do so. * Performance, in rare cases where network round trip dominates execution time and I need more than one plain SQL statement; this is only the case for the integrated 'procedural' languages. One could accomplish something similar by running the application's code closer to the machine, and I think that'd be better, actually, but requires some orchestration.

mryan 14y ago

I think the flood of replies disagreeing with you suggest you might want to rethink that assumption. Another reply to your post said you are making a 'religious argument' - I think there is some truth in that. If you had said "in my experience, shared procs are not a good place to store business logic", that would have been your opinion, and no-one could argue with you. But you stated, as fact, that "business logic should be written in code, not in data and not in the database". This is not objectively true for all companies, and can be easily disproved. And was disproved, by all the people who said this assumption is incorrect. Throwing around the names of authors does nothing to help your case (useless "appeal to authority"). I have read some of Robert Martin's work (but none of Martin Fowler's) and still think storing business logic in database rules can be a very good idea.

EugeneOZ 14y ago
"And was disproved" - lol. It was just disputed, but not disproved. I don't care about flood of some anonymous on HN, I more care about articles and books, written by really experienced authors.