4 ms·
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
by 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 agoHow 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.