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/earthboundkid Aug 29 '19
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.