Relational And Storing Objects

See ObjectRelationalImpedanceMismatch

Someone very generally said that is tough/painful/slow to store and retrieve objects from a relational database. The thing isa very fuzzy, I think some major complaints are related to MappingInheritanceHierarchiesToRelationalSchemataInvolvesCompromises.

Anybody can help in better defining this problem?

There are many ways in which even a good OO-to-relational mapping layer can cost you, in terms of run time performance, relative to a well crafted SQL-centric application.

Such mapping layers generally give you good code reuse at the expense of runtime performance. -- JeffGrigg

Another problem with storing objects in relational databases is that a relational database cannot store private data (maybe this is RelationalBreaksEncapsulation). By definition, the data in a relational database is public, e.g. accessible with sql tools, scripts etc. So any attempt to enforce class invariants in a relational database will be very hard. Objects do this by selective constraints on what kind of operations are supported in the object's interface. RDBM's will provide an uniform access mechanism, which will prevent such constraints from being enforced. Databases do support some forms of constraints, but these are much less flexible (and better behaved) than what can be implicitly enforced with class invariants.

This causes two things: First, any database that was designed with principles similar to what you'd normally use for designing private data for objects will be very brittle. Private data representation within objects can be changed at will without it influencing any other part of the system. Not so with databases, database schema is part of the interface to the database, not part of the internal private representation. Secondly, any object that stores information read from a database will have to perform unnecessary conversions and synchronization with the the database to its own internal format. -- EsaPulkkinen

DatabaseNotMoreGlobalThanClasses tends to disagree with the characterization of databases as more "global" than classes. It begs the question, "global to/from/for what?" --top