programming and human factors
by Jeff Atwood
I had an opportunity to meet Ted Neward at TechEd this year. Ted, among other things, famously coined the phrase "Object-Relational mapping is the Vietnam of our industry" in late 2004.
It's a scary analogy, but an apt one. I've seen developers struggle for years with the huge mismatch between relational database models and traditional object models. And all the solutions they come up with seem to make the problem worse. I agree with Ted completely; there is no good solution to the object/relational mapping problem. There are solutions, sure, but they all involve serious, painful tradeoffs. And the worst part is that you can't usually see the consequences of these tradeoffs until much later in the development cycle.
Ted posted a much anticipated blog entry analyzing the ORM problem in minute detail. It's a long post. But unless you're a battle-scarred veteran of the ORM wars, I highly recommend at least skimming through it so you're aware of the many pitfalls you can run into trying to implement an ORM solution. There are a lot of magic bullets out there, and no shortage of naive developers.
Ted's post is excellent and authoritative, but it's a little wordy; I felt like I was experiencing a little slice of Vietnam while reading it. Let's skip directly to the summary at the end which provides an great list of current (and future) solutions to the ORM problem:
- Abandonment. Developers simply give up on objects entirely, and return to a programming model that doesn't create the object/relational impedance mismatch. While distasteful, in certain scenarios an object-oriented approach creates more overhead than it saves, and the ROI simply isn't there to justify the cost of creating a rich domain model. ([Fowler] talks about this to some depth.) This eliminates the problem quite neatly, because if there are no objects, there is no impedance mismatch.
- 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, eliminating many (but not all) of the aforementioned issues; there is no "second schema", for example, because the only schema used is that of the object definitions themselves. While many DBAs will faint dead away at the thought, in an increasingly service-oriented world, which eschews the idea of direct data access but instead requires all access go through the service gateway thus encapsulating the storage mechanism away from prying eyes, it becomes entirely feasible to imagine developers storing data in a form that's much easier for them to use, rather than DBAs.
- Manual mapping. Developers simply accept that it's not such a hard problem to solve manually after all, and write straight relational-access code to return relations to the language, access the tuples, and populate objects as necessary. In many cases, this code might even be automatically generated by a tool examining database metadata, eliminating some of the principal criticism of this approach (that being, "It's too much code to write and maintain").
- Acceptance of ORM limitations. Developers simply accept that there is no way to efficiently and easily close the loop on the O/R mismatch, and use an ORM to solve 80% (or 50% or 95%, or whatever percentage seems appropriate) of the problem and make use of SQL and relational-based access (such as "raw" JDBC or ADO.NET) to carry them past those areas where an ORM would create problems. Doing so carries its own fair share of risks, however, as developers using an ORM must be aware of any caching the ORM solution does within it, because the "raw" relational access will clearly not be able to take advantage of that caching layer.
- Integration of relational concepts into the languages. Developers simply accept that this is a problem that should be solved by the language, not by a library or framework. For the last decade or more, the emphasis on solutions to the O/R problem have focused on trying to bring objects closer to the database, so that developers can focus exclusively on programming in a single paradigm (that paradigm being, of course, objects). Over the last several years, however, interest in "scripting" languages with far stronger set and list support, like Ruby, has sparked the idea that perhaps another solution is appropriate: bring relational concepts (which, at heart, are set-based) into mainstream programming languages, making it easier to bridge the gap between "sets" and "objects". Work in this space has thus far been limited, constrained mostly to research projects and/or "fringe" languages, but several interesting efforts are gaining visibility within the community, such as functional/object hybrid languages like Scala or F#, as well as direct integration into traditional OO languages, such as the LINQ project from Microsoft for C# and Visual Basic. One such effort that failed, unfortunately, was the SQL/J strategy; even there, the approach was limited, not seeking to incorporate sets into Java, but simply allow for embedded SQL calls to be preprocessed and translated into JDBC code by a translator.
- Integration of relational concepts into frameworks. Developers simply accept that this problem is solvable, but only with a change of perspective. Instead of relying on language or library designers to solve this problem, developers take a different view of "objects" that is more relational in nature, building domain frameworks that are more directly built around relational constructs. For example, instead of creating a Person class that holds its instance data directly in fields inside the object, developers create a Person class that holds its instance data in a RowSet (Java) or DataSet (C#) instance, which can be assembled with other RowSets/DataSets into an easy-to-ship block of data for update against the database, or unpacked from the database into the individual objects.
Ted quickly posted a followup entry which addressed common criticisms of his original post. If you have an itchy left mouse finger poised over the "comment" link right now, you may want to read that first.
Personally, I think the only workable solution to the ORM problem is to pick one or the other: either abandon relational databases, or abandon objects. If you take the O or the R out of the equation, you no longer have a mapping problem.
It may seem crazy to abandon the traditional Customer object – or to abandon the traditional Customer table – but picking one or the other is a totally sane alternative to the complex quagmire of classes, objects, code generation, SQL, and stored procedures that an ORM "solution" typically leaves us with.
Both approaches are certainly valid. I tend to err on the side of the database-as-model camp, because I think objects are overrated.
I'm not sure why everyone keeps trying to cram everything into tables. I guess it's one of those "if you have sql then everything starts to look like a set" sindrome...
I've been lucky enough to work on projects where I got to work on both sides of ORM issue. This meant I got to fix the tables, views, procedures or the code depending on which part got me more longterm profit. I can't imagine having to build either part around an existing other.
I'm currently researching db4o and find it very useful. It's got all I need for my next project. The project has a nice tutorial which you can use to quicky scan through db40 features. The hardest part for me is letting go of some relational axioms when designing the system. Like keep trying to use Id's to store relations between objects.
Is this to say that Java/.NET does not have good ORM solution? ;)
And what is "good"?
There is a horrible cliche of people saying stuff along the lines of "blah blah blah Ruby solves this" or "blah blah blah Rails blah" in response to almost any technical blog post.
But in all honesty ActiveRecord, the ORM part of Rails, is really good at what it does, partly because Ruby is a scripting language so it doesn't have to know the structure of the database ahead of time. It even lets you inherit your relational-objects in a slightly scruffy but very effective way. I've been very impressed in all my dealings with it.
Like most of the things about Ruby it's not really doing anything hugely clever, just simple things with great attention to detail that leave you thinking "why wasn't everyone doing this already?"
Ben Moxon on June 28, 2006 3:54 AMHave you guys even looked at DLINQ yet? Problem solved.
Fibber on June 28, 2006 4:34 AMSo should I make another "oo sucks" t-shirt Jeff and send it to you? Its great for baiting "you'll-take-objects-from-my-cold-dead-fingers-I-never-saw-a-pattern-I-didn't-like" team-mates. http://jcooney.net/archive/2005/09/24/6824.aspx
JosephCooney on June 28, 2006 5:16 AMInteresting how this conflict still rages. The reality on the ground is that for large enterprises, anything *but* a relational data store is going to seriously hamstring your access to that data. Object to disk storage techniques that don't use a relational database simply silo off that data so it is nearly useless outside the original program.
However, even those tools that *can* serialize to a relation successfully make the mistake to too tightly coupling the object with the data model. A better idea for scalable solutions is to use an ORM tool to create a data access layer. Then build your business logic on top of those objects as needed to express more complex object behaviors. Personally I use LLBLGen because of the strong typing of the entities it produces and fact it avoids using text strings in favor of field enumerations. You really avoid a lot of runtime errors that way.
However, the exact tool is unimportant. What is important is that your business logic layer creates the abstractions *above* the data access layer that your ORM produces, thus avoiding that close coupling.
The downside is that you can't simply dump state by serialization. The upside is you gain more version independence and interoperability with other tools. I think that's worth the extra work on the business logic layer.
Wesley Shephard on June 28, 2006 5:48 AM"the only workable solution to the ORM problem is to pick one or the other"
Come on Jeff - you're starting to sound like one of those developers that believes in absolutes. Each of the six options has merit in certain situations. We should be open minded enough to pick the right solution for the problem at hand.
Jeff M on June 28, 2006 5:57 AMI find that too often all problems are generalized into one solution. In fact, taking out "reporting" and all aspects of a project that look like reporting (anything with rollups or pivots, for example), and using specialized tools or an alternative approach to ORM for those is quite a good way to clean up a project. Take out difficult slicing and dicing of the data, and suddenly ORM solutions are very workable for all the other rote work. It's a simple yet highly neglected concept.
Marcus on June 28, 2006 6:17 AMWow, there is a whole bunch of "not getting it" here.
People, having to model your data twice is bad. BAD!
Stop denying it. Stop pretending it's somehow a good thing. It's not, its tedium, it impedes productivity and bloats and slows down code. Its a source of bugs, of performance problems, of general frusteration.
And for what? Why do we keep trying to shove our objects into relations? What's the big payoff? WHAT?
Damien Katz on June 28, 2006 6:45 AMTed's point is not that "there is no good solution to the object/relational mapping problem". If that's you're takeaway, you've completely missed the point.
ORM tools can be used successfully. The point is that they only cover about 80% of the O/R mismatch problem - beyond that they produce diminishing returns. Our mistake as an industry is viewing these tools as a silver bullet, rather than as a partial solution to a problem that will never have a perfect solution.
none on June 28, 2006 7:07 AMSpeaking about ruby, there seems to be something even better than the ActiveRecord (that maps Relational schema to Objects, this one has the different approach, it uses RDBMS just as storage for the objects):
http://www.nitroproject.org/rdoc/og/index.html
Did anyone here try Cache from Intersystems?
Esad Hajdarevic on June 28, 2006 7:08 AMthe notion that a mismatch exists rests on a false assumption about how computers really work. that assumption is that method text must be stored with data. real computers don't keep multiple copies of method text: one copy of method text, multiple copies of data (data is what distinguishes one object from another). method text is identical for all instances.
there is, therefore, nothing to be gained by redundantly storing (in a language and application restricted way) method text.
a concerted review of the Relational Model, as told by Codd, shows that this is really an object oriented view of the world: data and all that manages it reside together in an open (in the sense of univeral access) manner. data integrity is part of the data store, and thus supports open access. remember, Codd's paper was titled "A Relational Model of Data for Large Shared Data Banks".
point 2 is just fancy words for saying "we like locking up our data in our code, just like we did back 1960's with COBOL/VSAM" (for the MF-ers). what, in the world of politics, is called reactionary. moreover, and the part that really ticks me off, is that "bean paradigm" programming is not distinguishable from COBOL copybook programming. this is not progress.
real progress is being made with approaches that generate the UI (which is just a fungible artifact of the datastore, and therefore irrelevant (c) ) from the database schema. i swear, people who yap about mismatch can't possibly know how either the RM or SQL data really work. and probably think that there is such a thing as "an object model". i feel better now.
Buggy Fun Bunny on June 28, 2006 7:12 AMAnd for what? Why do we keep trying to shove our objects into relations? What's the big payoff? WHAT?
Umm-- so that the data can be stored in an easily accessible manner in a commodity RDBMS server?
I see a whole bunch of "not getting it" here, too. "Introspect" the schema from the RDBMS. Don't represent the schema as XML, or as code. Generate your UI dynamically based on the schema. If you need more metadata than "introspecting" the schema from the RDBMS gives you, define a standardized way of storing that metadata in the RDBMS.
I feel silly, but to expand on my prior comment:
Buggy Fun Bunny has it again. Inheritance hierarchies _can_ be modeled in an RDBMS. It may be difficult with SQL, but SQL isn't the relational model-- it's a just query language. Don't judge the relational model by SQL.
Even staying inside the SQL box, though, look at PostgreSQL and the inheritance support there. Anything you can do with PostgreSQL's inheritance you can do with any other RDBMS that supports triggers and stored procedures, if you want to code up the infrastructure.
adjuster on June 28, 2006 7:45 AMUmm-- so that the data can be stored in an easily accessible manner in a commodity RDBMS server?
So the reason for converting object to relations and back -- with all the bugs, performance problems and tedium that come with it -- the reason that makes all the problems worthwhile, is the ability to store the data in a relational database?
Damien Katz on June 28, 2006 8:54 AMI'm not sure what tedium and bugs are being talked about. You have your ORM generated mapping layer that does the mapping the simplest way possible: one entity type per relation. It is automagically generated from the schema, including views, procedures, etc. You have business logic that needs to manipulate those entities... that manipulation would be the same (supporting business rules) whether the *data* was stored via serialization, in relations or in a rutabaga. Finally you have your UI, which talks to the business layer, oblivious to the storage choice made.
Now there are some types of apps that don't need to co-operate with anything else in the world. In those cases, store you data in a rutabaga if it makes for happiness! In large data storage systems (you know, the ones relational databases are designed to address) I would prefer not to require a specific language (or vegetable) to read the data. I know my clients are happy they can use comfortable reporting tools and analysis tools instead of going through import/export hurdles.
Wesley Shephard on June 28, 2006 9:47 AMI do not agree. I use Gentle.NET and it solves more problems than it creates. (www.mertner.com/Confluence)
It's not a magic solution, but overall you can develop 30-40% less code once you understand the framework (quite simple to be honest).
New 2.0 version (for .NET 2.0) is on its way and it looks very promising. There's a tradeoff, of course, but once you go OR all the way, you can't go back ;)
Ok, I've been a programmer for 16 years, mostly straight-up client server / Windows applications and have more recently been moving into "web applications".
In this amount of time, I have seen these frameworks come and go every couple of years. They all seem to preach one or more of these points:
1. Your programmers (who are apparently stupid) don't need to know anything about the underlying data model!
2. Writing native .SQL in your applications is too hard to maintain and write! (again, stupid programmers)
3. UI should never never ever talk directly to your database. (whatever....)
How, exactly, is adding ANOTHER layer between your application and your database going to make maintaining anything EASIER? And how is it going to make ANYTHING faster than a well-written piece of SQL?
If someone makes a change to the db schema that is going to throw something off down the line, SOMEONE has to go and either fix the application or the framework, or whatever.
Here are a couple of tips:
1. Yes, seperate your DB and UI code into seperate classes/objects, if possible. It makes things much easier to debug and maintain.
2. Make your classes/objects work as a logical group of related funtions or temporary data stores.
3. If you have to process data that the client doesn't need to process, do it in a stored procedure on your database, if possible. Don't select 1,000,000 records from your database into your application/"framework" for processing if you don't need to.
Yes, this is some simplistic stuff, but it's just a few points that I live by. If you are a decent programmer and can keep your code logical and well-commented, no other (decent) programmer that steps in after you should have a problem maintaining your code.
I think programmers need to learn more about how databases work, particularly how to write stored procs and triggers in their database of choice (if they are available).
It has always been my view that programmers should not try to isolate themselves into a black hole, not knowing or understanding how their own data is stored.
Shawn C on June 28, 2006 11:26 AMI'm not sure what tedium and bugs are being talked about.
I'll help you find it. I just "Googled" the internet, and found this: a href="http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx"http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx/a
It's a very detailed article about all the problems with ORMs. Quite timely to the discussion, eh?
pedant on June 29, 2006 5:39 AMJeff I can't thank you enough for this post. I have been battling it out with a few developers on our CSK forums (Commerce Starter Kit) regarding OR/M and how much I hate it. The interesting thing is that most of these guys (as you mention) like it in concept but have never actually had to support it. I have, and every time I've removed it (Gentle, NHib, NetTiers).
I take a hard line on this: OR/M is laziness and serves programmers, not clients. You stick thousands of lines of code between your DB and BLL and you're going to tell me your coding for speed and scalability? Never.
Vietnam is not a bit of an insensitive analogy (lives aren't lost using OR/M ... well except for the devs who throw themselves out a window once they realize how limited they are with it).
Hmmm.
I seem to have misunderstood what the impedance mismatch actually is (or everyone else here has, but that seems unlikely).
For the record, I thought it was about working on *instances* versus working on *sets*. The mapping between columns and properties has its problems, but I don't find it a big deal day-to-day. The harder thing to overcome is the conceptual difference between "each instance can have different behaviour" and "every instance will have the same behaviour".
Or, to quote the sqlalchemy ORM developers:
"SQL databases behave less and less like object collections the more size and performance start to matter; object collections behave less and less like tables and rows the more abstraction starts to matter."
Both endpoints of the continuum are relevant, and I've worked on each of them, and a couple of shades in-between. Different trade-offs need to be made for different requirements (that's not news, surely?).
The whole columns-properties thing feels like a mechanical problem, not an interesting one.
Owen
Owen Phelps on June 29, 2006 6:33 AM"I just "Googled" the internet..."
I read, and even understood the article. However, I find it overblown because I'm one of those who have accepted a data centric universe. In a large enterprise, if you accept a data centric universe (and for interoperability, that would seem wise) then you don't try to shoehorn objects into relations. You use objects generated by your ORM to encapsulated your relations and build your business logic objects on top of those building blocks.
I guess I'm confused by the commentary that makes this seem "unsolved". Systems I have designed are used by tens of thousands of users every day, with high concurrency and various access patterns (reporting, transactions and multi-screen edits) and it just hasn't become a problem. Neither web products nor desktop products have made me curse my choice of ORM tool, nor have I encountered situations where I have been unable (or even hard pressed) to create a solution. Nor do I feel like I'm writing tedious and buggy code, since the only code I write at the business layer is to handle, you know, business rules?
Sure, if you insist that serialization is the only storage model you can stomach, relational databases aren't all that hot. However, I haven't used serialization for years because I have to share my data with reporting tools and other apps.
Wesley Shephard on June 29, 2006 8:59 AMWhy are people suddenly finding it so difficult to get data in and out of a relational database? This is not a new concept.
I'm no master of database technologies, but it seems that the relational database is just about the most efficient way of storing data right now in terms of speed and storage.
How do you enforce cardinality and referential integrity in these new "Object" databases? Or do you even care anymore? How is data integrity kept in check?
It does seem kind of silly. People have been using "relational database" methods of storing data even before the database was enforcing referential integrity, etc. on it's own.
They were just enforcing these rules on their own on the client/application side.
So, let's say that in a "proper" relational database, I need to change the item number of some product. Let's say that 500,000 people have already ordered this product and each order needs to reflect this new number.
Do you have to iterate through every order object in the database to update the item number?
Shawn on June 29, 2006 9:43 AMI totall agree that O/R Mappers are a total waste of time. They are only needed when the structure of the object is different from the structure of the relational database, so the soltion is simple - keep the two stuctures exactly the same.
I do this by having one object per database table, and each object has coded into it the structure of the table it's dealing with. "But", I hear you say, "this means you have to change the object each time you change the database". Apart from the fact that even with an ORM you would still have some code to change I have found a way to make this even easier. I maintain all database structures in a special Data Dictionary application, so if I build/change a database table all I do is import it into the dictionary, then press a button to export the table structures to my application. The Dictionary generates the code that the application needs so I don't have to do it by hand.
Easy peasy lemon squeezy.
Tony Marston on June 30, 2006 3:07 AM"I take a hard line on this: OR/M is laziness and serves programmers, not clients. You stick thousands of lines of code between your DB and BLL and you're going to tell me your coding for speed and scalability? Never."
Autogenerated mapping layers bring a consistent method for abstracting out relations so the business layer can work with them, nothing more, nothing less. "Thousands of lines of code" is a red herring: I assume you also have forworn all the libraries, runtimes and other conveniences and code machine code without an assembler? Every day programmers work with many layers of abstraction that makes their life easier, yes. It also allows for reliability (the lower layers are tested foundations) and yes even scalability if you build resources for caching, concurrency control and the like into your mapping layer.
It would seem that such abstractions would be the bread and butter of someone providing a "commerce starter kit".
Wesley Shephard on June 30, 2006 4:31 AMI love when people like shawn don't look into a subject but do have something to say about it. They ask questions like "How do you enforce cardinality and referential integrity in these new "Object" databases? Or do you even care anymore? How is data integrity kept in check?"
How do you go about learning new things Shawn? Or do you not care anymore?
*These new (sic!) things called object databases have plenty of ways for you to define your schema. You just no longer have to do it twice.
"and yes even scalability if you build resources for caching, concurrency control and the like into your mapping layer"
So I need to come up with a mapping model, which duplicates my existing DB model, then cache it, access it at run time so it can tell me how to "SELECT * FROM [Table]"? I have to be honest - to me this is a problem that has sprung up from ASP.NET in general - the ability to do too much, too easily, too often.
I just read my daughter "The Cat in the Hat Returns". OR/M reminds me of the Cat pulling all the little cats from inside his hat to clean the pink off of the tub/dress/shoes/floor/walls/snow. Eventually he gets to Little Cat Z who has the Voom, which is all he needed in the first place ... anyway...
No, abstractions are not our bread and butter. Abstraction overload causes our users confusion and it keeps me inline. Some things deserve to be painfully obvious.
Rob Conery on July 19, 2006 2:37 AMwe are using Datasets in our framework with the Enterprise Library.
And it works fine!
No objects... OK DataRows, DataTables are objects, but they are simple to use and powerfull.
Merge() Sort() RowState...
Peter Gfader
Peter Gfader on August 18, 2006 6:19 AMOne problem with object relational mapping is that you have to spend money on LSD first in order to use it without difficulty.
L505 on July 18, 2007 7:32 AMORM like most computer concepts is not a finished product, but rather a step in the right direction. The glorified days of coding in binary are over, as are the days of COBOL, mainframes and punchcards. To get where we have come has been one step at a time, and ORM is another step towards realising that we don't have to make things complicated just because it's cool or it's "right".
Our company developed another ORM, Habanero, because that was what was needed for the real world, where projects have to be delivered on schedule. It made complete sense and I can barely imagine doing it the old way.
Erichero on July 30, 2007 4:13 AMyeah i definitely agree its a step in the right direction this is obvious by the fact that VS2008 will hav DLINQ or LINQ or watever MS decides to call it :P . However the point is that ORM is the way forward as long as it continues to evolve. DLINQ is cool bt is mainly concerned with the data layer, the still the other layers and issues to worry abt and most frustrating one is generally the GUI side, something that most ORM tools out there havnt tackled yet, havnt looked at Habanero. Ive searched the net, only finding stuff abt chilli's .. link to Habanero plz?
VillageProgrammer on August 1, 2007 1:03 PMCurrently I do some research on this topic to find a new approach. Does somebody know a product or technique that uses a similar approach like http://www.signumsoft.com/objectdatabase/ where the mapping basically already happens on the database?
Daniel on August 16, 2007 4:24 AMBasically the good name of ORM has been tarnished by terrible code generators that spit out reams of barely passable code, and "comprehensive" packages that force you to manually do every aspect of the mapping - and then spit out reams of barely passable code.
You can't change it, you can't maintain it, and it sucks.
NHibernate can usually make a passable object model for next to any schema. If you are starting a new application then use something following the Active Record model, its simple and it works. Its probably how you wanted to design your database anyway. Diamond Binding is far and away the leader of this category - no code generation, no manual mapping, it works out the box. Can't speak highly enough of it, its saved our development budget tens of thousands of euros.
jlacie on October 2, 2007 11:28 AMI think that Linq solves "The Data Retrieval Mechansim Concern" quite nicely. You actually COULD do the query he lists.
I believe it would look like this:
from p1 in Person
from p2 in Person
where p1 != p2
where p1.Spouse == null
where p2.Spouse == null
where p1.IsThisAnAcceptableSpouse(p2)
where p2.IsThisAnAcceptableSpouse(p1)
select new Couple { p1, p2 };
Most ORM tools have their place somewhere in society. We can talk purism and enterprise-level applications, but Joe Soap who's new to IT doesn't have the capacity for an NHibernate - it's homepage alone will cause him to break into shivers.
For all the Nokia and Toshiba and Microsoft developers out there building pyramids, there's also the humble citizen building an app for the local corner shop who needs something simple, quick and, dare I say it, dirty.
Erichero on November 9, 2007 7:12 AMTo use an ORM?
Or not to use an ORM in my next project?
I am totally BLANK!
I have had problems in all projects irrespective of whether I used ORM or not. But I keep on using new technologies(i.e. ORMs, frameworks) because they keep me interested and motivated to build new projects
:D
You really must read the book "Java Persistence with Hibernate", at least Parts 1 and 2 about object-relational mapping impedance and how many problems have been solved.
I guarantee that you would look at this issue from an entirely different viewpoint.
Krishna Kumar on December 15, 2007 10:15 AMThe Real Meaning of Object Relational Mapping
Transparently persisting data from objects to a database is the idea behind the use of Object Oriented databases and ODBMS. If an O/RM acts in this regard they should in fact call themselves an O/OM (Object-Object Mapper) because they are not really dealing with relational data. On the other hand normalised data requires an O/RM to produce its objects by sourcing its translations from different tables in a database.
The reason why the war cannot be won is because the wrong weapon is being used, an O/OM. GURA is a new breed of O/RM and fulfills all the requirements of Object Relational Mapping. Check it put at www.gura.com.au
"Personally, I think the only workable solution to the ORM problem is to pick one or the other: either abandon relational databases, or abandon objects. If you take the O or the R out of the equation, you no longer have a mapping problem."
Thank you.
Justin Megawarne on February 15, 2008 1:00 AM"yep it is what it is"
When OR/M is the Vietnam of Computer Science, I just saw the My Lai of Computer Science in a proprietary (read invented just here) implementation of an OR/M.
(just to make it clear: I do not mock the people who suffered way back when!)
ralf
ralf on July 21, 2008 1:26 PMSimply put O/R mapping is usually justified by comments like...
it gives me objects and it takes care of transactions.
I have two classes:
JdbcBroker.java
TransactionManager.java
I don't need any ORM any Hibernate or any other junk solution.
I have no idea why it is so hard for everyone else.
Maybe they should learn the SQL language instead of hibernate.
People use O/R M because they don't know SQL very well. (entry level programmers)
What is funny... or not funny... is that after so long, the application is so slow and sluggish and messy that they start writing ORM-SQL directly and get results sets again to speed up parts of the application.
Have you ever seen a five year old run in circles?
Can you say maintenance nightmare on jelm street.
It's like using your old ford truck to pull your new semi.
frantic on September 30, 2008 12:35 PMI couldn't have said it better myself.
On a quite Chevy night, you can hear a Ford rust.
On a long Hibernate night, you can see a shooting JDBC star.
semantechie on October 1, 2008 9:50 AMHIBERNATE IS A NIGHTMARE JUST LIKE THE VIETNAM WAR
nightmare on October 2, 2008 11:28 AMvery good article and thread... not enough discussion in the world regarding whether object oriented middle tier approaches are cost and risk effective!
it all comes back to basics, what we learned in school about program elegance and such. way too much effort has been applied by software vendors to sell middle tier tools than concentration on whether those tools are necessary.
i find the argument that you either go oop or not at all a very compelling one. in the environments that i work in, all of the applications are data centric. the application is modeled relationally… for all the reasons that keep relational databases the kings of the resource/persistence layer. data centric applications should _always_ focus on maintaining the relational model all the way through to the presentation layer.
attempts to take “data centric” applications and make them “object centric” in the middle tier is like slamming a square peg in a round whole.
either one goes “data centric” and gives up the benefits of the object world or goes “object centric” and gives up the benefits of the relational world. no free lunch!
Do you still feel this way about ORM tools (espcially for web development).
A couple of companies I use have them (like DevExpress and Telerik).
awake on November 20, 2008 9:13 AMI had to laugh at the comment that talked about relational databases being the most efficient and fastest way to store data.
The relational model and RDBMSs were adopted in the 1980s IN SPITE OF their slowness compared to the then-dominant pointer-based hierarchical databases. Ask yourself why that was. If you can't figure it out, buy an old edition of Date's An Introduction to Database Systems (Vol. 1) and read it. The old editions are really cheap (used), and have discussions of the problems of competing data models.
When I started looking into OOP in the early 80s I characterised it to my colleagues as systems programmers discover the Entity-Relationship model. Building on what Buggy Fun Bunny said above, many of the seminal OOP papers in the 1970s referred to The Entity-Relation Model of Data in Proceedings of the 5th International Conference on Database in their bibliographies.
So not only the physical model (of relations), but also the semantic model (of entities, attributes, and relationships) underpin OOP. If there's an Object-Relational mismatch, you're doing OOP wrong.
Again, as Buggy Fun Bunny says, the 1960s and 1970s were spent learning why we should separate data and function. Storing them together in application-specific formats is exactly the wrong thing to do. We've been there before, people.
And as for Jo Script-kiddy who wants to put up a web site for the corner shop -- why would she use C# or Java? That's just masochism, when there are appropriate tools like PHP around.
I'm with "old_fart" here. If you think there's a mismatch between OOP and RDB systems, you're doing it wrong.
Here's my approach, honed by 10 years' experience and my comp sci degree (which was long enough ago that we studied network, hierarchial, and THEN relational databases in that order, since all were still currently in use by corporations -- we learned C, then C++ because it was new and cool, and I didn't pick up Java until I got out in the world).
FIRST, before you do anything else, get an entity-relationship model of your data. Learn how each piece of data relates to the others, so you can actually make a wise decision about what to do with it. The ER model should be an accurate model of reality; don't pull any optimization stunts here, or you'll regret it later!
NEXT, build your database. The database ALWAYS comes first, since it's separate from your application and will exist long after your application has faded from memory. You must plan your database according to the assumption that other applications will use it, and that it will be extended to contain data about things you haven't even thought of yet. And put your database in 3NF, so future developers' suffering will be minimized.
Once you have an actual data model, print out your ER diagram and let your developers design their object model. Their object model should be based on your entities and relationships -- object models are supposed to be based on reality, and your ER diagram is an expression of that reality. In other words, it should work like this:
Reality --> ER Model --> Object Model --> code
NOT the other way around. If developers recommend changes to the ER model, they should be made to justify them by showing how the ER model doesn't accurately reflect reality. "coding convenience" isn't an appropriate justification.
Finally, you build the actual software. You'll probably use an incremental/iterative development model, and update the schema and object model as you proceed... That's to be expected.
In the blog post, I'd be firmly in the "manual mapping" (#3) camp.
Note how this all works out. Because you're basing your ER model, and then your object model, on REALITY, you'll end up with a self-documenting system that is relatively intuitive to maintain. It'll last a long time, too, because as long as the real-world entities you've modeled the whole system on continue to exist, the system will still be relevant. Changes in technology won't ruin the system, because you've made the database the beating heart of it -- you can always export and re-import your database structure to a new DB, and you can reuse your object model with a new language if something new comes along.
The whole idea here is, DO SOME ANALYSIS, and base your systems around an actual design, something that can be ported to new systems and extended over the years.
Of course, I'm an old fart too (38 years old!). And to me, the real problem is that "these damn kids today" don't want to do any up-front analysis! They think that just because the waterfall model is a train wreck, they have a free pass to skip analysis entirely. Lazy little buggers and their PhP... THEY do cute little websites and they assume ALL development is about cute little websites.
Tsk, tsk, tsk... They just have NO IDEA...
Ah, well, glad to see I'm not the only old fart still around.
I didn't dig deep into the comments, but from my skimming I find no one come forth and say why people want to put stuff in relational databases in the first place...
It turns out, your application is not the entire world. In most businesses there are several applications that need access to the same data. And before replies with the usual "make a service and let other applications access the data through it", I'm not going to mention legacy applications (because you are stuck with an RDBMS anyway in that case), but I will mention ad-hoc queries.
Sure, you could build extensive ETL processes feeding a datawarehouse, but in the real world, there are people inside companies asking for all kinds of stuff to help them make decisions or to attend to specific oneshot needs within the organization (one shot stuff that often can't be answered by the established datawarehouse). Being able to answer those queries without an RDBMS would mean full replication of all data from your object database into an RDBMS. It's better to just go relational from the start.
John Clarke on August 23, 2009 2:08 AMIt seems like the mismatch is often a false dilemma in the service of academic purism over creating actual working software. As BFB implied, tables can usually map pretty closely to the object model. In the odd case where they can't a view can almost always solve the problem. OR/M's do a great job of mapping objects to relational data as long as they haven't stepped into a pre-existing conflict, and if the data architect was already at war with the software architect then an automated tool isn't the cause or solution to the conflict.
Jon Galloway on February 6, 2010 9:47 PMBorland solved the ORM problem for me with ECO. It's not perfect, but it saved me literally weeks of coding. When I found a little addon called ECOAccess it saved even more time. And it manages to generate a pretty clean database schema as well (I spend up to half my working hours as a DBA, so I'm not blowing smoke there).
Of course, it's Delphi only, you won't be finding a version for Visual Studio any time soon.
Anyway... RDBMS has its advantages, OOP has its advantages, and SOA also has its advantages. These things aren't just useless extra "layers", they're tools which all serve different purposes (RDBMS for working with large datasets, SOA for implementing complicated business rules, OOP for writing more type-safe and maintainable code).
If you stop viewing these concepts as being at war with each other and start viewing them as different perspectives of the same solution, all the long-winded arguments about OOP and ORM and HBO and WTF start to look a lot more like lame excuses for ordinary human inertia (i.e. the overwhelming urge to keep doing things the way you're doing them now, at any cost).
Aaron G on February 6, 2010 9:47 PMAs many posters have said, ORM comes down to the tools (frameworks). I've been using Rails for a few months now, and I'm impressed at its ease and functionality.
For .NET, the Castle Project ( http://castleproject.org ) is also outstanding. Their ActiveRecord implementation is built upon NHibernate and allows your classes to be mapped using attributes, making for a smooth and joyful experience!
Jarrod Dixon on February 6, 2010 9:47 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |