« Mit Dexter in der Schlange | Main | Flugzeuge im Himmel »

Donnerstag, Mai 24, 2012

OrmHate

Irgendwie hat MF immer die richtigen Dinge zu sagen: Gerade ist bei uns eine DBA vs. Dev-Team-Diskussion entfacht und sie dauert noch an.

Many people treat the relational database "like a crazy aunt who's shut up in an attic and whom nobody wants to talk about"[3]. In this world-view they just want to deal with in-memory data-structures and let the ORM deal with the database.

Unsere Tante heisst Onkel Torsten; und ja, ich bin im Prinzip auch der Ansicht, dass die DB das Objekt-Modell unterstützen soll und nicht umgedreht.

Es wird hoffentlich weniger hässlich als Vietnam, aber dieses Essay hat einige Zustände sehr prägnant zusammen gefasst:

Discussions of inheritance-to-table and association mapping schemes also reveals a basic flaw: At heart, many object-relational mapping tools assume that the schema is something that can be defined according to schemes that help optimize the O/R-M's queries against the relational data. But this belies a basic problem, that often the database schema itself is not under the direct control of developers, but instead is owned by another group within the company, typically the database administration (DBA) group.

In many cases, developers begin a new project with a "clean slate", an empty relational database whose schema is theirs to define as they see fit. But, soon after the project has shipped, it becomes apparent that the developers' ownership of the schema is temporary at best--various departments begin clamoring for reports against the database, DBAs are held accountable to the performance of the database thereby giving them cause to call for "refactoring" and denormalization of the data... Before too long, the schema must be "frozen", thereby potentially creating a barrier to object model refactoring ... In addition, these other teams will expect to see a relational model defined in relational terms, not one which supports an entirely orthogonal form of persistence--for example, the "discriminator" column ...

So, then, the next task is to create a "Query-By-Language" approach, in which a new language, similar to SQL but "better" somehow, is written to support the kind of complex and powerful queries normally supported by SQL
The problem here is that frequently these languages are a subset of SQL and thus don't offer the full power of SQL.

Was bleibt also: Es gibt viele Wege nach Rom - der gutklingende führt interessanterweise als Beispiel db4o an, ein OO-Datenbanksystem, mit dem wir 2008 mächtig baden gegangen sind.

Summary: Wholehearted acceptance. Developers simply give up on relational storage entirely, and use a storage model that fits the way their languages of choice look at the world. Object-storage systems, such as the db4o project, solve the problem neatly by storing objects directly to disk. ... While many DBAs will faint dead away at the thought, in an increasingly service-oriented world ... it becomes entirely feasible to imagine developers storing data in a form that's much easier for them to use, rather than DBAs.

Andere, eher elementare aber trotzdem gut illustrierte Fakten zum Object-Relational Impedence Mismatch :

Object systems are typically characterized by four basic components: identity, state, behavior and encapsulation
[Date04] and [Fussell] define the relational model as characterized by relation, attribute, tuple, relation value and relation variable.

JOINs are among the most expensive expressions in RDBMS queries.... As a result, developers typically adopt one of the other two approaches ...: they either create a table per concrete (most-derived) class, preferring to adopt denormalization and its costs, or else they create a single table for the entire hierarchy, often in either case creating a discriminator column to indicate to which class each row in the table belongs.
Unfortunately, the denormalization costs are often significant for a large volume of data, and/or the table(s) will contain significant amounts of empty columns, which will need NULLability constraints on all columns, eliminating the powerful integrity constraints offered by an RDBMS.

Inheritance mapping isn't the end of it; associations between objects, the typical 1:n or m:n cardinality associations so commonly used in both SQL and/or UML, are handled entirely differently: in object systems, association is unidirectional, from the associator to the associatee ..., whereas in relational systems the association is actually reversed, from the associatee to the associator (via foreign key columns).

Allgemeine Regeln oder Grundsätze werden auch gestreift: Law of Diminishing Returns, "the Slippery Slope", "the Drug Trap", "the Last Mile Problem"

Erstellt von tixus um 6:20 PM Kategorien: Software + Java
Powered by
Thingamablog 1.1b6