(Apologies if some of my terminology is off, I have not seen much on this subject and am using be best terms I could come up with)
Should data model logic live in the database schema?
I am making a distinction here between business logic and data model logic. By data model logic I mean things specifically to do with data integrity, like cascading deletes (ex. deleting a customer should also delete all the customer's addresses, deleting a user should remove all that user's group memberships), rather than higher level business logic and rules. I have read through "How much business logic should the database implement?" and "Business logic: Database vs code" and absolutely agree with the general consensus there that business logic should live in code, not the database.
Part of me likes the idea of the database enforcing the structural rules of the data model. It can be argued that it is a database concern. It can simplify the code side of things; you just need to delete the main entity itself and the database will handle the appropriate cleanup automatically. And it'll help reinforce the structure of the data if anything is ever bypassing the application and hitting the database directly (ex. making manual changes via SQL, pulling in data from another source via an ETL type stored procedure).
But then the other part of me feels like that is the wrong approach. The application code now has to assume that the database will handle this properly. If ever a data model logic concern comes up that cannot be handled by the database and simple constraints, now you have data model logic living in two different places: some in code, some in the database. And if you ever choose to change your data storage to something else, you now have to re-implement that same logic on the new storage system.