Hidden Issues When Modeling Data Using Business Objects
A common approach to data modeling is to use a data modeling tool (such as Erwin) to create a schema and then from the schema to create business objects using an Object Relational Mapper (ORM).
The reverse process is less common when data modeling is performed using business objects (such as POCO / POJO), from which the schema is generated using an ORM.
This question is being asked about non-trivial systems containing hundreds of database tables.
I was under the impression that many designers / architects steer clear of the second approach due to a number of hidden issues, such as data migration between schema revisions, reduced design control and SQL tuning. What are the real problems?
source to share
For me, the usually real problem is this:
"This question is being asked about non-trivial systems that include one hundred database tables.
Added unnecessary complexity. This happens regardless of what you mentioned, but it is usually the bulk of the Real Problems.
Note that if you have a "system containing hundren of database tables" you should not be talking about one system / context, but a set of applications / contexts. Regardless of whether in the end you end up putting in the same DB, the complexity is solved without modeling it as one huge thing that is all in one huge DB. Bounded context is the buzzword for today.
Starting with POCO does not mean that later on you won't be able to renew / customize where needed. This is another real problem, premature optimization.
source to share