Arguments That The Object Relational Impedance Mismatch Does Not Exist
Arguments That The Object Relational Impedance Mismatch Does Not ExistRestating my view, I'll eventually consolidate the arguments in ObjectRelationalImpedanceMismatchDoesNotExist.
My view is that ObjectRelationalImpedanceMismatchDoesNotExist as a real thing, that is, the two domains have no fundamental problem to be resolved. Therefore it does not exist per se; it is not essential to the two models being incompatible.
Before I lay down my real (constructive) arguments on the problems at hand, I need to lay out some fundamental things about databases in general, the relational model, and issues related to transactions and concurrency, things which I've already begun to do.
I'm not sure if wiki is the right place to substitute for a book on the subject, but it has been shown that many experienced OO developers have a lack of understanding of the fundamental issues related to database theory, therefore an informal introduction is needed in order to avoid confusion and misinterpretations of what I am saying.
On the other hand, not even the OO theory is quite free of misconceptions, false obviously true facts and other things like that. One of the fundamental things about OO theory that is not known by a vast majority of OO developers is that there is NO single, unitary, tried and true OO theory, and this has to be kept in mind while talking about ObjectRelationalImpedanceMismatch. A single practical unanimously accepted OO way of doing things much the less.
However for many people Object Orientation is reduced to the following equations:
Therefore, my take is that there is no conventional wisdom that ObjectRelationalImpedanceMismatch, because there is no fundamental theoretical work that demonstrated with some kind of logical rigor the existence of the mentioned set of problems.
Every single author has just stated that a problem exists and presented his/her solution (without bothering to define it and/or prove if it is a legitimate problem). No author has tried to discuss, for example, what object identity means from a data modeling perspective (domain modeling perspective if you want). Every single author has tackled issues such as inheritance as self-understood, no need for a proper definition.
Let's pick the one work at hand CrossingChasms:
The following sample of problems are drawn from there :
What if we do it the other way around? Let's say we have first a sound logical data model. Then we work against this data model and find the best physical way to represent relations, entities, even parts of an entity , in specific use-cases that we deal with in an OO way. Then we'll hardly have any impedance at all.
And the whole literature on ObjectRelationalImpedanceMismatch, goes on like that. We have our beautiful nicely designed objects. It doesn't matter if they make a consistent and sound data model. It doesn't matter if it is a level too low (like I said, just fill in the method code and the application is done), DatabaseIsRepresenterOfFacts and DatabaseApplicationIndependence also are secondary. How do we store our beautiful objects in this clumsy relational database. Why don't we have pointers and arrays like we do in our OO languages?
[Refactorer's note: I've pulled the following responses out of the text above and put them here, just so I could read it. I don't know if they're by one author or many, but they made the original thesis impossible to follow. -- JonathanTang]
What you are essentially saying here is not that the ObjectRelationalImpedanceMismatchDoesNotExist. You are saying instead "if you idiots would simply give up on doing object modeling then you would find no problems in connecting to a relational database". You're not debating anything about connecting from an OO model to a database. You're trying to convince us that building an OO model (as understood by Booch, Rumbaugh, etc.) and as implemented in an OO language is an unfounded and dumb idea and that that if we would simply give up on that notion then our lives would be so much simpler. But that's the problem. MOST OF US on wiki agree that OO modeling IS a valuable activity. Thus, the OO relational mismatch exists for us. If you want to give up on that fundamental notion, then of course it doesn't exist!
x.method() REALLY IS different from method(x). The difference is in polymorphism. You see, you can substitute the method that is actually invoked both by inheritance or by the use of interfaces. Show me how that can be done otherwise in any language that's not object-oriented! Pick one of the statically typed functional languages (ML,Ocaml, Haskell, Clean, Mercury). Go study it and you'll really learn about polymorphism. It will do you much good.Costin, this is why having a discussion with you is so infuriating. Of course method(x) is THE SAME AS x.method() IF you are referring to a language with Multimethods (and yes, I've used CLOS before) or that allows generic programming. But you NEVER SAID THAT. So, why don't you just say "object orientation requires polymorphism as a language feature" and we can ALL agree.
Inheritance is WELL understood. Why would someone have to define it? Can't you be bothered to go back and read any of the literature on object technology? Oh - based on the fact that you don't seem to understand what polymorphism is, then probably not... Ok, that's your opinion. What's the latest book you read on OO theory? But anyways, if your that smart maybe you have something positive to contribute to LiskovSubstitutionPrinciple, LiskovWingSubtyping, CircleAndEllipseProblem and related pages.
Re: creating the object model. Well, if one is using an OO language, then one must use objects. Oh, you're saying that we shouldn't use OO languages? Then I guess we should use what....?
Re: inheritance of abstract classes. Uh... You really have problems with this inheritance of behavior thing, don't you... Apparently you do. Tell me how you store "behavior" on disk.
Re: doing the logical data modelling first. I challenge you to demonstrate that. I think either you'll end up with a LOUSY OO design that no one in their right mind would want to maintain, or you'll discover the problem all over again...
Let's say we have first a sound logical data model. Then we work against this data model and find the best physical way to represent relations, entities, even parts of an entity , in specific use-cases that we deal with in an OO way.
This smacks of BigDesignUpFront. -- MarkAddleman
Beyond that, Costin's statement that we work against *one* data model and find the best physical way to *represent* this, is a direct statement of there being a Mismatch. Were the two models in close agreement, no work would be needed on anyone's part; and this discussion would not exist.
Interestingly enough, I have much direct experience with Costin's suggested way (an object-oriented tuple layer) as well as object-level persistence layers and legacy procedural database coding.
Lastly, consider the fun & helpful inability of the SQL equals = operator to compare null with null. Those who have worked with parameterized queries, or snapshot optimistic locking, will curse the committee which didn't provide an operator to handle this. This is just one glaring example of the mismatch, and a less common one at that.
No, a logical and sound data model can also be evolved without the need for big design upfront. think of DatabaseIsRepresenterOfFacts.In the beginning you might want to tackle a subset of facts, and then extend it as needed. As long as you'll be careful about the consistency you won't have problem to evolve it.
And related to Mark's question I like to add that the fact that you have an relational data model (schema) does not mean that you have a good data model. On the contrary, data modeling is still rather an art and we only have some criteria to validate it.
Well guess what Costin, object modeling is still rather an art and we only have some criteria to validate it too, but that doesn't mean it isn't useful.
However great chances are that if you have an objectual domain model (it really is a data model in the end), some inherent data modeling problems will be hidden under the covers without you being aware of it. For example I have yet to see a discussion as to when an object model is normalized. Also I'm not aware of any wide use OO language other then Eiffel (which does it partially) that allows me to specify data integrity constraints. -- CostinCozianu
Costin, I give up. The point most of us have been trying to make, slowly, laboriously, and as gently as possible is that practically the ObjectRelationalImpedanceMismatch exists because the way current systems are built in current OO languages leads to problems and headaches when combined with current database technologies. Personally, most of us don't care that all the problems can be theoretically solved if (a) you used a better language and/or (b) you gave up all of your years of experience in building scalable, reliable, maintainable systems in OO languages and did something else. Practically, it exists. If you are convinced that the collective experience of the entire object modeling community is worthless, then you are entitled to believe that. However, we have seen otherwise. Nothing you can say will change that. Theoretically, more power to you... -- KyleBrown
What if they can be practically solved? What if there already are practical examples of whole complex systems built in OO languages, very scalable, against a relational back-end, without any impedance mismatch, the only problem being that their logical data models were not object models in the sense that you want an object model to be, and thus you can say that the OO layer was subordinated to the relational layer?
[If the result doesn't leave you with an object model in the sense that we want them to be...i.e. collections, then it's not OO, thus is wasn't practically solved at all, it's an entirely different solution.]
Are you willing for instance to give up on object identity for instance? Are you willing to give up on representing collections? This leads to very practical advantages. -- CostinCozianu
[Yes, it also leads to non-OO systems. There may not be a single grand OO theory, but of the many that do exist, almost all require object identity. Date and Darwin's proposed system isn't OO by anyone's standard but their own. Giving up those thing may give practical advantages, but they also render the system into something other than what most of us accept as OO, therefore the impedance mismatch obviously exists. What you're really saying is that if your name is CostinCozianu and you write code like CostinCozianu and don't care about having an object model, then it doesn't exist. You can't say write functional code and whalla, there is no mismatch, because the mismatch exists with OO code. You can't solve the mismatch by not writing OO code, that's simply denial of the issue.]
Do we have to give up polymorphism? Is this part of giving up on representing collections? -- MarkAddleman
Yes, I recognize systems as Object-Structured or perhaps Object-Based which break inheritance or unary joins into distinct instances. And that this provides a moderate degree of the benefits of OO; code structuring and some degree of encapsulation; with minimal disagreement with the relational model.
Actually you can achieve polymorphism in this structure with interfaces. Unless the version of Delphi you used was too old :-) Don't see why one would have to give up collections, was this really necessary?
Hmmm. It seems after a great deal of heat and wandering about the problem space, Mr. Cozianu's arguments have essentially come down to "Object-Relational impedance mismatch is caused by using object-oriented programming methods". Give up object identity, don't have an object model, only a logical data model. It's OK to use an OO programming language though. Hmm, I wander what that language is, and what the code looks like. Some code samples would be extremely instructive. Also of interest would be some evaluation of how maintainable this codebase is, how long it took to develop it, and how well it represents the business processes, concepts, and rules. I've been warned away from making bold bets, but nevertheless I suspect that the system in question does not exhibit the characteristics of good OO programming, nor take part in the benefits of those practices. It might perform exceptionally fast, though. -- StevenNewton
Steven, do you have any theoretical or empirical evidence that object identity, and other kinds of anti-relational features that make the distinction between an object model and a data model, really help you in tackling application against large shared data banks? What are the characteristics of good OO programming, after all? I challenge anyone who can really say, I know what OO programming really is, because it really is several distinct things. Like I say in other place, I bet that in 10 years people will look upon Java and Smalltalk like at some kind of Cobol (providing they don't change drastically, which I very much doubt). I really like to start a page HistoryOfObjectOrientedIdeas? and clear this whole mess, where everybody pretends that OO is what he thinks it should be (Smalltalk, Eiffel, whatever), and nobody acknowledges a single little alternative approach ....
Empirical evidence shows that applying the so called principles of OO programming to the category of problems that the relational databases are in, leads to the kind of embarrassing collections of anti-patterns and workarounds to anti-patterns like EnterpriseJavaBeans (the EntityBean chapter). On the other hand ObjectRelationalImpedanceMismatch often serves as a ready made excuse to these embarrassing anti-patterns.
If you really think object identity is so fundamental (although no theoretical paper on OO that I know of looks at it as fundamental), would you care to join us at RelationalHasNoObjectIdentity, and provide a sample object model that justifies it? -- CostinCozianu
The best approach I know for unifying OO and RDB is the ShlaerMellorMethod. This is an OO method that explicitly includes data modeling, identity, normalization and constraints; in addition to associating behaviour with tables. Unfortunately things started to go wrong when CASE tool implementations started to drive it more towards traditional OO languages. But I still use it when programming using UML as source code. -- DaveWhipp
there is NO single, unitary, tried and true OO theory
Regardless of whether that is true or not, so what? Why does a theoretical underpinning have to be so important? Software development will never have a comprehensive theoretical underpinning - it is a SoftScience?, in the words of StanSilver. Progress in our field has been haphazard and messy. To be successful, we use what works. We try to do the SimplestThingThatCouldPossiblyWork. I know you and I differ on this point, Costin, but for me, ObjectRelationalMapping has not been the SimplestThingThatCouldPossiblyWork.
All the problems above illustrate the wrong approach, that first we should have an object model, which means we almost have an implementation, all that we miss is to fill in the code of the methods and we have the application ready
Say's who, you? The object model IS the solution to the problem being solved, of course we start with it, because eventually it will determine what data we have and even need. If you don't know what data you need, you can't build a database.
I certainly don't subscribe to this view, nor do the many OO practitioners I've worked with and whose books I've read. An object model does not make an application. IvarJacobson et.al. make this case quite convincingly in ObjectOrientedSoftwareEngineering. I've never encountered any learned software developer who believes a working system can be created by drawing a conceptual domain model (or logical data model) in a CASE tool and chucking the result over the wall for some junior programmers to flesh out the skeleton. We all know this is not how development works, and it is inaccurate to apply this generalization to the OO school of thought.
the upper level which is the logical data model
I think we're in violent agreement here, Costin. We're using different terms to describe the same thing. In UmlDistilled MartinFowler describes several different "perspectives" on domain modeling, including the "conceptual perspective" and the "implementation perspective". Personally I don't see much difference between a conceptual DomainModel, expressed as a class diagram, and a logical data model, expressed as an entity-relationship diagram. The key thing to understand is the abstractions in the problem domain, their attributes, and the relationships (including cardinality) between them. But here is where the difficulty begins: OO developers want to translate the conceptual model into an implementation model in an object-oriented programming language, and data modelers want to translate the conceptual model into a relational schema. OO developers can use intrinsic object identity to relate objects, while relational DBAs have to assign sequence numbers to avoid the anti-pattern of using attributes meaningful in the problem domain, which can be volatile, in primary keys. Under the premise that both an object-oriented programming language and a relational database have been selected for the implementation of an application (which is the operative premise that underlies this entire discussion), those two results have to be mapped to each other. The question always arises as to which should "drive" the other. This is the subject of a fair amount of KyleBrown's and BruceWhitenack's work in CrossingChasms. I'll ask you again: do you even advocate using an ObjectOrientedProgrammingLanguage at all? If so, how? For what? In what layer of architecture? (see FourLayerArchitecture, http://www.javasuccess.com/patterns/layered_arch_pattern.html, and http://www.javasuccess.com/patterns/service_based.html).
What if there already are practical examples of whole complex systems built in OO languages, very scalable, against a relational back-end, without any impedance mismatch
Cite them. Tell us the DesignPatterns that were used to construct them. After all, as stated on WikiHistory, "this site was, and remains, dedicated to PeopleProjectsAndPatterns".
Empirical evidence shows that applying the so called "principles of OO programming" to the category of problems that the relational databases are in, leads to the kind of embarrassing collections of anti-patterns and workarounds to anti-patterns like EnterpriseJavaBeans (the EntityBean chapter).
The conclusion doesn't follow. That's like saying "apartment buildings in communist countries are ugly; therefore all architectural principles known to man must be worthless". I'm already on record saying that EntityBeans are a bad idea; I couldn't agree with you more. But you can't infer a conclusion about OO principles in general, or even EnterpriseJavaBeans in particular, much less DomainModels and plain old java DomainObjects, from that one observation. EnterpriseJavaBeans are valuable in many ways: the notion of deploying an application into a container is valuable; container-managed distributed transactions are valuable; and stateless SessionBeans are valuable because they provide a de-facto standard way to implement FacadeAtTheDistributionBoundary.
I know you and I differ on this point, Costin, but for me, ObjectRelationalMapping has not been the SimplestThingThatCouldPossiblyWork. -- Randy
Believe me, if I was to really choose what is the SimplestThingThatCouldPossiblyWork, I'd say C (maybe C++) + embedded SQL.
That's an absurd statement, those languages would force you to write far more code than a more modern higher level language. C and C++ are rarely the simplest thing that could possibly work.
It runs very fast, too. Ok, my second choice would be something like Delphi, and unfortunately the now dead NetDynamics, maybe ASPs + Visual Basic also contend for the SimplestThingThatCouldPossiblyWork. While x-layered architectures stand no chance of competing as the SimplestThingThatCouldPossiblyWork. Wouldn't you agree? I have some reserves on the SimplestThingThatCouldPossiblyWork as an universal principle. -- Costin
This is one area of ExtremeProgramming that I'm still trying to demystify for myself. When it comes to the SimplestThingThatCouldPossiblyWork, I definitely do believe in OnceAndOnlyOnce, and refactoring to achieve it. However I also believe that the forces that drive you to layered architecture are real, and that layered architecture does a nice job of balancing them. I had the opportunity to hear RonJeffries speak in May, and he said that the SimplestThingThatCouldPossiblyWork is not necessarily the crudest thing that could possibly work, or somesuch. I like elegance and simplicity, but I also understand the motive to protect oneself from future variations (in layer-specific technology, or requirements, or whatever), and I've had good experience with using frameworks. Along those lines, I think the interesting question that is the germane premise in our whole debate is WhenAndWhyIsItValuableToImplementaDomainModelInAnObjectOrientedProgrammingLanguage? -- Randy
..... it is inaccurate to apply this generalization to the OO school of thought. -- Randy
Well, I haven't try to apply a generalization here, because I don't believe there's anything that can justifiably claim the title the OO school of thought. -- Costin
....I'll ask you again: do you even advocate using an ObjectOrientedProgrammingLanguage at all? -- Randy
Sure, I do advocate an OO language (despite OO not being the SimplestThingThatCouldPossiblyWork). Nowadays, I do program every day in Java, although I have a greater satisfaction in learning Scheme, and once in a while I long for a little raw C to get me out of Java. Now, other than the advocacy for an OO language, you stated a lot of things that will be needed to be discussed separately. For my personal taste, 4 layers architectures are already too much, and I certainly wouldn't advocate an OO language inside the database, at least no OO language as of today. -- Costin
Cite them. -- Randy
Ok, let's say I can't cite the ones I was involved in. I'll exemplify with classes of application architectures.
I'd be relatively alone in sustaining the relational model
I actually appreciate the relational model and relational databases, Costin. I think they're cool, and very good at what they do. That does not, however, mean that I believe the ObjectRelationalImpedanceMismatchDoesNotExist. It is not my intention to "single out" anyone, Costin. On the contrary, I've found this to be very stimulating discourse, and I thank you for launching it. You're not the first on this wiki to single out "the Smalltalk folks" for the opinions they hold. How about giving them a break - they have contributed much value to our professional field, as have many other "kinds" of "folks".
well, I hope I never said anything derogatory about Smalltalk folks, and as long as my English skills are concerned folks is a benign word. I did on occasions spelled out my concern with Smalltalk people who think that everything should be Smalltalk like. Here, I was discussing that Smalltalk developers have one more reason to stay away from RDBMSes unlike Java developers and C++ developers and so on. -- Costin
And the Smalltalk folks even have a very strong and practical justification for departing from the ways of relational model, that I haven' heard yet
You haven't heard it yet? In that case, please listen to ObjectRelationalImpedanceMismatch and linked pages such as ObjectRelationalMappingCostsTimeAndMoney and MappingInheritanceHierarchiesToRelationalSchemataInvolvesCompromises, for example.
(If trying to meld two paradigms is costly, then why not chuck Smalltalk instead of chuck Relational? You seem to imply the default is the other way around. -- top)
if you're programming in Smalltalk, neither Oracle, nor SQL Server, nor Sybase (not sure about DB2), offer you at least a minimum and decent client library for Smalltalk
{What about the libraries of say Perl or CommonLisp?}
They don't need to - the Smalltalk vendors do, by interfacing to the RBDMS vendors' C libraries underneath JDBC-like APIs. And there have long been multiple commercially-available Smalltalk ObjectRelationalMapping layers that sit on top of these APIs.
Going with the logic forward, first of all, this should cost a lot. Whereas client libraries are usually free, whereas Smalltalk vendors will necessarily be one step behind the client library features and consequently the product features, unless the Smalltalk vendor has a very strong relation with the RDBMS vendor, whereas there's an inherent impedance in any cross-language layer and especially in-between languages like Java,Smalltalk and C, whereas there are support issues and so on. It is no surprise to me that once it has been decided that the implementation language is Smalltalk, GemstoneS looks a lot more attractive than Oracle for pure technological reasons, even before high level concerns such as ObjectRelationalImpedanceMismatch. -- Costin
Yeah, I'm starting to think this is sort of a generic problem with any "technology stack". We used to see it in Smalltalk all the time. We'd be using EnvyDeveloper (a CM tool) and GemStone/S, and every time ParcPlace released a new version of VisualWorks, we'd have to wait several months for ObjectTechnologyInternational (the Envy vendor) and GemStoneSystemsInc? to catch up and re-release their products so that we could take advantage of the new features in the VisualWorks release. I've seen this with Java application servers and IDEs as well. They're always lagging behind the JavaSoft releases by some amount which, as you correctly point out, is a function of the closeness of their relationship with JavaSoft (and sometimes they may not want to be close for business reasons). I think it's a problem inherent in any technology platform that is led by one (big) vendor whose platform has a large cross-section. I'm sure Microsoft must have the same issue, although I'm not personally familiar. Some people call it the "TechnologyTreadmill?". It's kind of like the fashion industry - it keeps businesses in business :-) Meanwhile, we're just trying to build working systems on top of stable technology. Anyway, best regards. -- Randy
I argue that the object relational impedance mismatch doesn't exist (or maybe just doesn't matter), but I think I'm coming from the opposite direction from Costin. Relational databases are services external to a program, just like file systems, printers, networks, displays, keyboards, etc. None of those things are particularly object oriented. Sometimes we create object oriented views of them for our convenience, but at some point we have to deal with them using their own protocols (LeastFlexibleProtoclWins?). No one complains about impedance mismatches between OO and these technologies because there is no expectation that they exhibit object oriented behavior. The dream of transparent translation between objects in memory and records in relational databases obscures the reasons we use relational databases. If all you want are persistent objects, use a PrevalenceLayer. If you want fast ad hoc queries (and transaction management, and distributed access, and all that other jazz), use a relational database. Don't pretend that the RDBMS isn't a separate system you have to interface with and you'll be happier. -- EricHodges
Being separate facilitates DivideAndConquer. Modern economies depends on specialization, so it makes sense that software and info organization should too. OOP is okay for logic but crappy at attribute management. --top
I found this page after hitting myself against the Relational-OO wall. Most of the arguments found here didn't seem to come from people who have been doing things with systems of any decent size. Yes, dealing with relational structures in a system that only has 2 tables to join is not difficult at all. Issues do arise when the data that one is trying to store is widely spread among multiple (say, more than 5) tables. Say, an Employee. Creating a new employee with all the data that goes along that would require you to have Employee specific setup code to instantiate all other tables that are aggregates of employee with correct data. EmployeeShift?, EmployeePosition?, Employee.... and the list goes on. From a very practical stand point, this is a pain in the arse. Add to that that Employee is not your only 'object' (using the term very loosely to identify a Business level entity), and that this objects tend to change more frequently than not, and you have yourself a couple of programmers just keeping up with these pieces of code that allow you to create a new instance of a business layer entity. If you decided not to create these pieces of code that allow you to work with your Business Level objects, and decided that every application that will interface with the data will do its own database manipulation, you have a horde of application programmers that now need to be very intimate with the relational model of your database. IMHO a total waste of time. If you are using OO for your app development, you will need your business entities in some type of an object.
I agree with everything you just said, but still choose the object-wrapping-tables approach, why, because in the vast majority of business applications, performance isn't the biggest issue, flexibility, maintainability, ease of change, and enforcement of complex business rules are, which put's the object approach head and shoulders above the relational approach. When performance does become an issue, I write views, and objectify those. Most apps aren't yahoo and google and most apps only have a few concurrent users, flexibility and maintainability are more important here.
This is a bunch of non-sense thrown on this discussion with nothing to back it up. Phrases like "in the vast majority" BlahBlahBlah has no shred of documented research, quantitative and qualitative experiments to back this up.
That the vast majority of apps aren't yahoo and google and don't have those kinds of performance requirements isn't something that needs backed up, it's obviously true, or did you not read the whole paragraph?
In absence of those, it is elementary that you should use a more prudent style. Speaking from your own experience/gut feelings is not the same as speaking about well established facts. And speaking from my own experience many a "object" people's experience is invalid on this subject as they are quite incompetent with relational databases (including celebrity/guru figures) as documented in ObjectRelationalPsychologicalMismatch.
Nothing there shows object people are incompetent, it just show's the don't like the relational model as much as the OO model. Most object heads are far better with relational databases than you give them credit for, you just don't want to accept that they can understand both models and still prefer OO. Neither model is a perfect fit for all situations, both have their place, but the choice isn't relational or OO, because the relational model can't write software, period. The choice is for the most part procedural/functional/OO, supplemented by relational when it helps. Given that choice, its no surprise that we are forced to mix OO and relational to get what we want, and it's no surprise that we're not going to cripple our object models to better fit relational theory.
Likewise the propaganda style level of discourse "puts the object approach head and shoulders above the relational model", should be dropped. -- AnonymousDonor
What needs to be dropped is your arrogant assumption than anyone who doesn't prefer relational is incompetent, and your poor style of quoting half a sentence out of context to try make it look bad.
I agree that it often is, but a hell of a lot of business applications are rather trivial, and are much easier to implement with simple object models than with a bunch of hand written sql. I suspect you are talking much more about a multi application database than I am, so I'm not really disagreeing with you Dan. Database's are great for simple constraints, object are great for complex one's, there's room for all types.
Skeptical of complexity-handling claims. Example? See also AreBusinessAppsBoring.
I hope this does not sound too inflammatory, but until there is a rigorous definition of what exactly 'Object Oriented' development is then this argument is moot. It will be all things to all people. In contrast, and this is where folks who understand databases get frustrated with those who do not, a true relational database has a definite logical definition as defined by Codd. 'OOP' has no formal definition and that is the true mis-match IMO. Relational databases were designed so that you can *prove* that data integrity is maintained, a very important and practical goal (theoretical!=impractical).
Can anyone prove the claims, either logically (mathematically) or empirically (X% of the time with Y% confidence we have a z% drop in maintenance costs), that OOP provides better software (lower cost to maintain, less cost per feature, fewer hours etc.)?
OOP makes claims but as far as I know has not proven them, everything in this discussion for example is anecdotal.
Until there is a rigorous definition of OOP, then this argument is pointless. Because only then can we identify where the breakdown really exists.
But part of the reason for the mismatch is that OO *is* poorly defined. Relational is bound by rules that OO does not like being restrained by. Relational proponents believe that these rules provide consistency and a math-like ability to reason with cleaner conclusions and integrity, but OO'ers find them restraining. -- top
And it should be done in a generic non-programming language and environment neutral manner, such as Codd did with databases. Until then it is just a grab-bag of tricks, best practices, hunches and opinions. It is like saying 'There is a Calculus/Poetry impedance because it is difficult to turn Calculus into poetry'.
[There is no Calculus/Poetry impedance mismatch. I wrote my Physics midterm in rhyming couplets, sticking as close to iambic pentameter as I could. I even rhymed Gauss's law for magnetism (not in that form - I rhymed it as "del dot B") -- JonathanTang]
{Reason number 47 why geeks should be barred from poetry :-) }
In my personal practice I: 1) Think about the *information* problems first. 2) Think about the data generated. 3) Think about the operations on the the data and the 'objects' used or needed and the operations on those objects. 4) Start designing with the view that what I am really doing is defining an Algebra in a problem domain to solve information problems. I find when there is an "impedance", I either did something wrong, or I have to hack around a vendor specific database mis-feature (there are no true relational databases out there) or a language mis-feature.
-- PLopez
What's pointless is people who don't use OO or don't prefer OO (Costin and Top) telling the OO people that there isn't a mismatch... if all the OO people claim there's a mismatch, then there is, period. Saying "don't use OO" isn't a valid solution to the mismatch.
{For the record, I believe there is a mismatch, as described in TablesAndObjectsAreTooDifferent. -- top}
[Not all OO people claim there's an impedance mismatch. At least one of them (EricHodges) views relational databases as external devices with their own protocols. I don't claim there's an object-printer impedance mismatch or an object-speaker impedance mismatch either.]
{Perhaps a case of WrappingWhatYouDontLike. Just because you can treat a database as only a filing system does not mean that is all it is or can be.}
One guy is an exception, not a rule, most OO programmers feel there is a mismatch, so there is, it's a perceived mismatch, you can't talk it out of existence.
[I'm not trying to "talk it out of existence." I'm reminding you to avoid absolute statements.]
If all the people say the world is flat, does that make it true? What I am saying is that you can not prove that there is an actual, rather than perceived mismatch unless you can first define what OO is in a formal sense.
A perceived mismatch is an actual mismatch in practice, this isn't science, it's programming, there's no need for a formal definition of OO to acknowledge this.
And in fact if you think about database engines in the correct manner then you can OO, regardless of what DB you have on the back end (it just that a DB which does not follow the Codd Model cannot be proven to maintain data integrity, the programmer has to provide this functionality).
It's not about academic proof and formality - it's about real experience on real projects. Object relational mapping is a major pain in the ass. If it wasn't, then people wouldn't go around saying there's an impedance mismatch. --RandyStafford
And to further elaborate, most of us find not using objects to be a bigger pain in the ass, which is why we tolerate object relational mappings in the first place. Objects give what some of us believe is clean simple programs that are easy to reason about, and relational databases give us persistence, locking, queryability, etc... they just don't fit too well together without being forced to compromise one or the other, neither of which we want to do.
Who is "us" in "most of us"? Wikizens or programmers in general? MainstreamOopUsage.
So basically what Randy is saying is that it is hard. So what? No one said programming is an easy profession (maybe this topic should be retitled 'databases are hard'). What is stated above is that if you throw away the Codd model you must prove to me you can come up with something at least as good. Which is a tall order and probably much harder than learning to use a (at least quasi) relational database properly. Also, I don't understand how wanting to maintain data integrity is 'academic' or a 'formality'. Data is the only reason any of us have jobs. It all comes down to data in the end, storing it and manipulating it. Anyone who willfully ignores data integrity is definitely on the wrong path. I am not anti-OO, I use it all the time. I am however against programmers et. al. who do not understand the technology they are using. -- pjl
So what? Well, persisting objects doesn't *have* to be so hard, for one thing. Ask anyone who's used GemStone. Programming would be a more *valued* profession if we spent less effort fighting technology and therefore had more effort available to create RealValue for our patrons. I disagree with you about "what is stated above", PJL, and I don't have to prove anything to you. But we all have to prove to our patrons that we can effectively serve their interests, and we may have different deeply-held convictions about how to go about that based on the lessons of our experience. It's generally futile to try to convince each other that our convictions are superior. Let us collect different experiences, hopefully through experimentation, and learn from each other, and decide for ourselves based on results, which are the real proof.
But that's not what this page is about regardless. CostinCozianu asserts and attempts to argue that the ObjectRelationalImpedanceMismatch does not exist, when many veteran object technology practitioners have experienced it first-hand and written about it. For me, for complex EnterpriseApplications, I prefer the DomainDriven architectural style, and I've found that RDBMS persistence of DomainModels requires more effort than OODBMS persistence.
I'm not anti-relational; I've been using RDBMSes, and "properly", I might add, for 15 years, and I understand them and object/relational mapping quite well, thank you. What I regret is when programmers don't understand the consequences, for the entire profession, of decisions they make based on ignorance, dogma, or irrelevant flimsy arguments, instead of real experience on real projects.
EditText of this page
(last edited December 4, 2005)
or FindPage with title or text search