The problems appear when someone tries to use an ORM to solve a general problem. In particular, using an ORM to try to solve the “impedance mismatch” is going to fail.

For your application, the question you should be asking is not what’s presented to the user, but if the information needs to make sense to other users. If the information does need to make sense to other users, then you should design the database accordingly. If the data only has value to that one user, than an ORM may be safe to use.

The first time I read this blog, I only slight understood the concepts that you were mentioning. However, I am in the middle of reading a book “Data Access Patterns: Database Interactions in Object-Oriented Applications.” I feel that I have a better understanding of your arguments. Since I feel that my SQL skill are much stronger than my code skills, one of the thoughts that concerned me while reading the book was that implementing a ORM, was that the mind set of the ORM was to process data in singular pieces instead of larger chunks at a time. This would essentially eliminate 90% of the SQL that could be used to replace repetitive time consuming manual tasks in a application.

However, would you say that there are certain cases where using an ORM is useful. In my case, I am working towards developing an interface that will allow a user to view and interact with data as represented in the format of a diagram (an instrument loop diagram to be exact). Would using an ORM have any advantage when trying to displays data in a format other than the typical tabular format.

back ground: I am playing with implementing Netbean’s Visual Library into my application in an effort to display data in a format that engineers understand.

Any information can be expressed in many different structures. However, not all structures are equal.

“But the primary key is important to decrease the impedance mismatch”

I assume here that you are referring to a surrogate key, that is, a generated number that is visible to the application, but hidden from the user (and hidden from the business overall).

I already made the argument that surrogate keys are a bad idea here:

http://people.planetpostgresql.org/jdavis/index.php?/archives/4-Terminology-Confusion.html

Surrogate keys do nothing to decrease the real impedance mismatch, which I described in this article in detail. For just one instance, how does a surrogate key make the data in an application less context-sensitive?

“The transition to 100% object is not yet resolved because of the persistance that needs RDBMS instead of File Systems.”

Object oriented data structures are essentially graphs (or perhaps trees). Graphs are very difficult to work with compared to relations. Graph data structures have been around longer than relations, and the Relational Model was invented to solve many of the problems created by storing data in graph structures.

I think the “transition to 100% object” will never be complete, because I think it’s fundamentally a bad idea. Using object-oriented database management systems is a regression.

“The bridge between the Application data and a well designed database data is made automatically by tools but sometimes there is some pitfalls.”

You completely ignored the fundamental differences between application data and database data that I listed in this article. The differences are not avoidable by “tools”.

Hope that helps.

Mohamed ROMDANE

- Writing SQL by hand is bad.

- Mapping SQL to methods by hand is also bad.

- Automating the creation of SQL or its mapping to the OO (or other)
code saves time or other resources over the scope of the project.

In my experience, these are all false.

I think that’s a more promising line of research, because it’s using the equation “type is analogous to type” not “type is analysis to table (relation variable)”. Smoothing over type mismatches would be a great way to encourage people to use an RDBMS correctly.

The authors propose a database system that supports sophisticated data types, including type inheritance. They reject the “class = table” analogy.

Keep in mind that application data and database data are inherently different, for the reasons I list above. OOP and pointers are inherently closer to physical representations, and applications must inherently manipulate physical representations. So, an OOP approach to application design is natural.

However, at some point you need to translate that data into something with meaning outside of context and abstracted from physical representation. Relations are a great way to do that, and you absolutely can use complex types in your relations’ predicates.

Your code doesn’t know the meaning of your physical representations of data. That is, a pointer represents a “relationship” between two things, but that is arbitrary and holds little meaning. Only when you transform the physical representation to match a predicate does it have a logical meaning from which other code (not just humans) can draw inferences.