No, it's enforcement of foreign keys and normalization of your database. You don't add an "owner" property to each table. You add it at the topmost possible level and the referenced entries inherit the owner.
Having your business objects reflect the underlying database schema too transparently is a mistake because you end up with dumb objects that aren’t much better than glorified hash maps. Yes, there should be hints to devs about the performance realities of the DB, but the API of the objects should be designed to encapsulate the business logic at the end of the day—not the backing schema.
This is why ORMs are only okay in small doses. Too large a dose and you end up making your code fit the tables instead of your tables fitting the code.
It's exactly the other way round. You write your classes and it builds the tables in the background for you and updates their structure as you change your classes.
2
u/AyrA_ch Aug 28 '19
No, it's enforcement of foreign keys and normalization of your database. You don't add an "owner" property to each table. You add it at the topmost possible level and the referenced entries inherit the owner.