A common approach to data modelling is to use a data modelling tool (e.g. Erwin) to generate a schema, and then from the schema to generate business objects using an object relational mapper (ORM).
Less common is the reverse process where the data modelling is done using business objects (e.g. POCO/POJO's), from which the schema is generated using an ORM.
This question is asked in relation to non-trivial systems that comprise hundred's of database tables.
I'm under the impression that many designers/architects stay away from the second approach because of a number of hidden issues, for example data migration between schema revisions, reduced control over designing and tuning SQL queries. What are the real issues?
Best Answer
For me usually the real issue is this statement:
Unnecessary complexity added. This happens regardless of what you the approaches you mentioned, but that's usually the main part of the Real issues.
Do note that if you have a "system that comprise hundren's of database tables", you shouldn't be talking about a Single system/context, but rather a set of applications/contexts. Regardless if at the end you end up putting then in the same DB, complexity is tackled by not modeling it like one Huge thing that's all into a single Huge DB. Bounded context is the buzzword for that nowadays.
Starting from the POCO's doesn't mean later on you can't extend / tune where necessary. That's another Real issue, premature optimization.