4 ms·

Not sure what you mean about deploy/rollback difficulties. It is of course something to consider, but generally speaking modern rdbms have the most sophisticate

Not sure what you mean about deploy/rollback difficulties. It is of course something to consider, but generally speaking modern rdbms have the most sophisticated tooling around this in the ecosystem. Versioning and compatibility are of course concerns but that is true of any scheme you come up with. If you think you haven’t exported “business logic” to your data store in any case you are wrong.

scarface74 9y ago
If all of your business logic is in your code, there is one source of truth. I know when I deploy code from a certain branch or tag, all of the logic is right there. My build process creates an artifact and that artifact gets deployed through the entire pipeline - Dev/Qa/UAT/Prod. There is one source of truth. But when half your code is in stored procedures and the other half is in code, how do you keep them in sync? If I need to redeploy an older version, it's a simple matter of redeploying the artifact from v1. How do you make sure the code stays in sync with the stored procedure? I can honestly say, that any system I've designed from scratch has no business logic in the data store.
- kasey_junk 9y ago
  Do you have types in your schema? That’s a business rule. Do you have columns, business rule. Those might be business rules you are ok with having in your data store, but they are a point of sync between your code and the store that you have to manage. If your stored procedures are their to abstract your table structure for write operations they act as a way to make that sync easier not harder.
  - scarface74 9y ago
    How often do types change? Changing schema usually involves adding columns not deleting them. I'm not aware of a realistic scenario where adding a column isn't backwards compatible. As far as writing your domain model to a relational schema, you should be doing that as a single module (in process) or micro service (out of process) that all other code calls. Meaning changing the representation of a domain model should only require a change in one place. For a monolith it means redeploying one artifact. For a microservice, it means deploying that microservice. Even better with a nosql solution like Mongo, if you are using a strongly typed language. Your domain model is your schema. You change your schema and the data model changes. With some ORMs you can just change your object and it creates alter table statements for you - I personally don't trust them but it is an alternative.

scarface74 9y ago

If all of your business logic is in your code, there is one source of truth. I know when I deploy code from a certain branch or tag, all of the logic is right there. My build process creates an artifact and that artifact gets deployed through the entire pipeline - Dev/Qa/UAT/Prod. There is one source of truth. But when half your code is in stored procedures and the other half is in code, how do you keep them in sync? If I need to redeploy an older version, it's a simple matter of redeploying the artifact from v1. How do you make sure the code stays in sync with the stored procedure? I can honestly say, that any system I've designed from scratch has no business logic in the data store.

kasey_junk 9y ago
Do you have types in your schema? That’s a business rule. Do you have columns, business rule. Those might be business rules you are ok with having in your data store, but they are a point of sync between your code and the store that you have to manage. If your stored procedures are their to abstract your table structure for write operations they act as a way to make that sync easier not harder.
- scarface74 9y ago
  How often do types change? Changing schema usually involves adding columns not deleting them. I'm not aware of a realistic scenario where adding a column isn't backwards compatible. As far as writing your domain model to a relational schema, you should be doing that as a single module (in process) or micro service (out of process) that all other code calls. Meaning changing the representation of a domain model should only require a change in one place. For a monolith it means redeploying one artifact. For a microservice, it means deploying that microservice. Even better with a nosql solution like Mongo, if you are using a strongly typed language. Your domain model is your schema. You change your schema and the data model changes. With some ORMs you can just change your object and it creates alter table statements for you - I personally don't trust them but it is an alternative.