Object-relational impedance difference

Asked

Viewed 422 times

9

Basic questioning about Object-Relational impedance Mismatch, a topic I have little experience with.

  1. It really exists? (I’m sure you do; Martin Fowler and Ted Neward already talked about the problem, but does it really occur in all situations involving objects and relational database?)

  2. If yes, in which situations it usually occurs? (For example, it is a specific problem of systems where the domain model guides the design of the bank and not the other way around?)

  3. How it has been solved? (There are different "flavors" of Orms as well as solutions based on removing the "O" or the "R" from the equation)

  4. What are the limitations of these solutions?

  • The two articles cited in the question themselves present great answers (really very good answers!) to this question. And they are texts too long and in some moments too opinionated for the OS format. What exactly do you propose we solve here? You can ask a more objective question?

  • Remembering: "You should ask only practical questions, which admit answers based on real problems you have. Extensive and open questions diminish the usefulness of our website and remove other questions from the homepage." http://answall.com/help/dont-ask

  • @Caffé I wanted to arrive at a non-opinionated answer about the problem, if that is possible. If this is not possible due to a very wide range of scenarios, I would like a scenario-divided response that covers at least cases considered major or more common. If that’s the case I can rephrase the question.

  • @Caffé I would also like, given a scenario and the solution adopted (or the solutions) to solve the impedance problem, to explain in a didactic way its limitations, to give a basis of understanding to the beginner in the theme so as to be able to evaluate, with relative property, a new impedance solution with which they come across (which in most cases will be some form of ORM or non-relational DBMS). Even if the responses vary with individual experiences, the OS brings the advantage of providing the evaluation of the best responses and therefore a north for the beginner.

1 answer

1

Perhaps my answer is vague, but if we look at it, the question was too broad and I have no reputation to comment on.

Just you see the situation as follows, the proposal of the Orms is a lie. It is the same thing to say that you will mix water and oil. If you only need a liquid any mixture serves, but if you need to give emphasis on either side, you will have to give up the other.

What I mean is, objects are formed by two things, obligatorily: data and behavior, that is, a class that has no methods or functions, is not an object. It’s just a "Data Structure" or Data Structure.

How would you represent encapsulation in a database table? or inheritance? there is no way to embed behavior in a database table in the same way you do with an object, the two things in fact do not match.

But it is possible yes, to extract part of the two things and form very similar data structures that will probably meet your needs, everything is a matter of judgment. I don’t remember going through any situation where "Impedance Difference" was a surprise problem, the problem exists yes, we learn to live with it.

Edit:

The discussion in the comments made me think of a possible solution.

At this link : http://blog.8thlight.com/uncle-bob/2013/10/01/Dance-You-Imps.html the Uncle Bob describes how "Tables" are not "Business Objects" but "Data Structures" (or classes without method/functions) of which real business objects use as a resource.

One way to avoid "impedance difference" is to segregate the "relational object" from the business object. See an example:

Business object:

public class Carro
{
    public abstract string Placa { get; set; }

    public bool PlacaEhValida()
    {
        return this.Placa.Length == 7;
    }
} 

Relational Object:

public class CarroORM : Carro
{
    [ColumnName("plate_number")]
    public override string Placa { get; set; }
}

This way you avoid the temptation to think that the relational object is in fact an object and goes on to use it in a more similar way to a database table.

  • The reason is the hint of the downvote button: "this answer is not useful". It does not answer the question, is based only on opinion, does not present evidence, and moreover is harmful to the OS because it attracts a type of discussion inappropriate to the objectives of the portal. If you consider your answer vague, even if it is for the reason that the question is too broad, consider not publishing it.

  • @Caffé agrees with you, but I believe that for a question like this, it is difficult to explicitly answer something else, I do not have enough points to comment on, so I decided to make an answer properly. You yourself gave tips to the user who asked the question, and I worked up just to give the examples he wanted, there is not always material for this kind of doubt, in my opinion, it is up to him to judge.

  • The AP can also judge. It can up-vote question (like the whole community) besides being able to mark it as the chosen answer.

  • In fact the positioning of this response is similar to that of the Robert "Uncle Bob" Martin on the subject. My question then would be, "extract part of the two things and form very similar data structures that will probably meet your needs" does not exactly mean doing object-relational mapping, or at least a specific form of it?

  • @Piovezan This answer is in absolutely nothing like the positioning of Uncle Bob!

  • @Piovezan Exactly, but the problem is the name "object-relational". I don’t believe in the existence of such a thing, but there is a limit to how far we can go and it is definitely achievable (as you said, a specific way). What I have done is decoupled the objects used to make this relationship of my entities themselves. In this way database objects (or mappings) have only data and my entities have data and behavior, this separation allows changes made to the database object not to reach my entity. Understands?

  • @Caffé Are you sure? http://blog.8thlight.com/uncle-bob/2013/10/01/Dance-You-Imps.html

  • I am absolutely sure. I have studied this article a lot. He says, for example, that if you think that "the ORM proposal is a lie," you don’t understand the proposal.

  • @Caffé Sorry, but I did not find this statement in the article. On the other hand I found "You can’t store behavior in a database. And that Means you can’t store Objects in a database. And that Means there’s no Object to Relational Mapping", which in my view is very similar to part of the content of the reply, namely: "there is no way to embed behavior in a database table in the same way you do with an object, the two things in fact do not match."

  • @Piovezan A good article is made to be assimilated into its whole, not to be referenced by isolated phrases. And here I am in a discussion that I myself announced would be fruitless in the O.R. As I predicted, nothing has been added apart from the articles (on the contrary, it can serve well to distort them).

  • @Brenosarkis The code you posted in your issue can be considered an outline (unimportant aside comment Removed) of the ORM solutions used there.

  • @Caffé I apologize if I did not understand the article, I am asking about the content you extracted from it precisely to help me understand what the article says.

  • @Piovezan I did not extract any content from the article. The quotation part was copied from the question and the next part is one of the ideas passed by the article, notably by its conclusion that says, among other things, for you to use ORM at will since you do not confuse it with a mapping between your business objects and the database.

  • @Caffé "Extracted content" is a way of saying. I asked about the information you learned from the article. I think I understand why you say the conclusions are different. The answer suggests a specific object design to satisfy the impedance difference while the article approves any ORM tool provided it is clear at the time of design that the tool does not aim to link relational state to behavioral objects, just migrate states. For me this is curious because I thought designing like this would generate dif. of impedance by itself. So not always?

  • @Piovezan You have just presented a very nice question. Yes this tends to generate an impedance difference. Uncle Bob in this article makes it seem like he doesn’t give a shit (he even likes to save data on disk). He is an artist and an indispensable philosopher for the development. from our area, but p/ answer this your last question I recommend the Fowler article you quoted on Perg. original. There he says, among other things, that if you are going to use a bank you can yes perfectly consider this in the design of the solution (being that "consider in design" is different from "guide the design")

Show 10 more comments

Browser other questions tagged

You are not signed in. Login or sign up in order to post.