简体   繁体   中英

ORM - Does the Database Schema Drive the Entity Composition or Vice-Versa?

We've had quite a bit of discussion among our development group concerning whether the composition of entities should drive the database design, or should the database design drive the composition of the entities.

For those who have dealt with this, what has been your philosophy? Of course, not every entity maps 1:1 to a database table. But, for those that do, how have you handled this? IOW, which comes first, the database table and then a corresponding entity or an entity and then a database table to persist it?

Thanks.

"entity and then a database table to persist it"

The Entity is what your program manipulates. That's the essence of what's being processed.

The database representation of that entity (like flat-file representations or GUI representations) are just handy representations of the entity.

You may have to think a bit about DB representation when it comes to certain things that relational databases are particularly bad at. Many-to-many relationships, for example, require introducing an extra table because the database has limitations that your object model doesn't have. You may have some entity design considerations to cope with this, but those a few and well-understood.

The database is less important.

The Entity definitions are central and essential.

Your database will likely outlive whatever application you build today. All the performance and the scalability are going to be driven by your database schema. A sound database model is the foundation on which any application is built, and I'd say is where you should invest most effort in design and testing, for it will give the biggest benefits.

That being said, of course your application will prefer to manipulate domain entities, and manipulating unnatural entities driven by relational theory as opposed to business entities will just complicate things. My view is that is the role of ORM to match the two, as best as possible. But whenever inevitable conflicts appear, the right of way should be given by the driving factor of your performance and scalability: the database schema.

I would say that you build your logical data model, and build the database and objects corresponding to that.

In fact, I would question the assumption that the database table and corresponding entities can't corresponding. I've rarely if ever seen a case where they really couldn't (if you are building an application from the ground up). Also, I would say that every time the object model and database schema diverged, it introduced a lot of problems.

I've come back around to the idea of that everything is simplier if you make them always match, however heretical that may be.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM