Hidden problems when modelling data using business objects

views:

194

answers:

Hidden problems when modelling data using business objects

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?

+1 A:

For me usually the real issue is this statement:

"This question is asked in relation to non-trivial systems that comprise hundred's of database tables."

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.

eglasius 2009-09-22 06:04:15

Oh please the riduculous premature optimization thing again. Database design requires thought into optimization before building as databases are far harder to refactor than application code. Code that will be less performant (by using something known to usually be less performant) should be avoided from the start. Performance is critical to databases not an afterthought and design time is when it must be considered if you want a database that will perform well. Premature optimization is meant to avoid looking for that little bit, not to avoid thinking about optimization in the design.

HLGEM 2009-09-22 17:05:31

@HLGEM ok, I challenge you, where did I say that there must be no design of the system? that you shouldn't consider performance when designing/coding your system? that you shouldn't build reasonable code for the given scenario? ... it Is premature optimization when you are needing plenty of extra DB features to fine tune it, when you are better off addressing that code/design you are referring to i.e. the one that will make a several X differences in performances and not just some 10-30%. And y, I understand that for a system with 100+ million people login everyday its different ...

eglasius 2009-09-22 17:19:48

Seems to make sense, something that a teacher told me on college on the first day of a programming class in year 1999 “divide and conquer”, simple statement easy to apply and hard to visualize but with experience. Of course all this, in the context of a good design and architecture.

2009-09-22 18:25:23

ansaurus

tags:

views:

answers:

Hidden problems when modelling data using business objects

related questions