Discussions

News: Avoiding the Quagmire - Part II of Ted Neward's Vietnam paper

  1. Ted Neward has posted "Avoiding the Quagmire," the follow-on to his rather popular article on "The Vietnam of Computer Science," referring to the concept of object/relational mapping. It, like his recent Tech Talk with TSS, focuses on Db4o as an object database, and offers real solutions (for some problems!) rather than merely pointing a problem out. Discussing one of the issues with O/RM, Ted says:
    In many respects, the object-table mapping problem is reflective of the larger problem, that of the dual-schema problem, in that in a traditional object/relational world, two sets of entity definitions are in play: one defined by the programming language itself, the other by the relational model using SQL DDL. This sets up an inherent challenge, as now two sets of definitions must be kept up to date as the system grows and evolves, either by "slaving" one to the other (frequently seen by the use of code generation tactics, either from schema to classes or the other way around), or by editing/adjusting the two separately and hand-tuning the mapping between them as necessary. This creates a tension between the two, and frequently developers are forced to make sacrifices in the purity of both models in order to keep the two in sync with one another. Again, in an OODBMS, the fact that the class definitions are the only schema present means that no such “dual schema” problem exists; the domain model need not be slaved to the storage definitions, and the storage definitions need not be twisted into strange formations just to support the storage of a rich domain model.
    Partly associated with Ted's authoring of this essay, Christof Wittig (CEO of Db4Objects) recorded a podcast with TSS, talking a little more about Db4o. Check it out.

    Threaded Messages (45)

  2. giggidy giggidy giggidy goo
  3. let the flame war begin[ Go to top ]

    everyone put on your fire retardent jackets for the flame war that shall begin shortly :)
  4. hehe[ Go to top ]

    Vietnam War -> one of the most popular and unsuccessful wars in US history ORM -> one of the most popular and successful technologies in enterprise software development Fantastic analogy.
  5. Re: hehe[ Go to top ]

    I hate to look "ass kissy" or anything (I think Gavin knows I'm not already from outbursts made here and maybe one jira ticket a long long time ago ) - but yeah I have to agree. . This whole premise sounds like such B.S. Amazingly enough he picked one thing that is unquestionably a) The only major jee spec that was successful. (I'm ignorant of most of them - hence I hope the major thing saves me from having to be more in the know...) b) Was implemented outside of Sun and before any spec existed. c) Is unquestionably the #1 favorite of almost any java developer working with a DB these days. And we all know finding something most java developers agree on is really a huge accomplishment. Which is of course hibernate. I think Sun and Ted should both take a closer look at this and the history of most of the non JDK based specs and try to learn something. :)
    Vietnam War -> one of the most popular and unsuccessful wars in US history
    ORM -> one of the most popular and successful technologies in enterprise software development

    Fantastic analogy.
  6. Re: hehe[ Go to top ]

    How stupid again.... yet another proof how questionable it is to take advices from you guys in a enterprise enviroment.... This not discounting ORM as a "valid", if not useful technolgy, but i think Ted makes very useful points, which anybody who is seriously considering to make substantional investions, has to consider and adress carefully. Many war's were successfull, which disastrous results. Technology becomes very quickly legacy. Fantastically constructiv input from Gavin. Just about like this bla, bla
  7. Are you sure about it?[ Go to top ]

    I agree with you that ORM is most popular one. But it is not most sucessful. Getting popular is just because there is no other clever choice yet. Something like HQL and EQL, it will never convince me very much. At this point of time, I definitely believed Ibatis is way better than other ORM (sorry, I did not treat Ibatis as ORM). You may have ton of reasons and statistic to prove I was wrong, that is just my two cents experience.
  8. It, like his recent Tech Talk with TSS, focuses on Db4o ..
    OK, I am really uncomfortable pointing this out myself, but for the second time (i.e. the second article on this subject on TSS) I missed the part of the post where it explains the relationship between Db4o and Ted. Ted is an independent consultant, and is not an employee of Db4o, but that makes it even more important to point out that he is working for Db4o (precisely because it's not self-evident). If you don't point it out, it makes Ted look bad, and it makes TSS look like just another sleazy "pay for play" site. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  9. Clarifications[ Go to top ]

    It, like his recent Tech Talk with TSS, focuses on Db4o ..


    OK, I am really uncomfortable pointing this out myself, but for the second time (i.e. the second article on this subject on TSS) I missed the part of the post where it explains the relationship between Db4o and Ted. Ted is an independent consultant, and is not an employee of Db4o, but that makes it even more important to point out that he is working for Db4o (precisely because it's not self-evident).

    If you don't point it out, it makes Ted look bad, and it makes TSS look like just another sleazy "pay for play" site.

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
    'Tis a fair question, Cam. Let me set the record straight.
    One, I am not an employee of db4objects (the company that writes/sells db4o).
    Two, I have taken money from them: they sponsored this follow-up paper, but exercised no editorial control over it. The paper is all my own perspective, and I insisted on certain elements being present, such as those areas where an OODBMS is not an attractive approach.
    Three, I do not, and will not, "evangelize" any particular technology, but I do, and will continue, to point out where technologies can be of use to programmers, particularly if they are technologies that are not commonly considered or known. The OODBMS is one such technology, and frankly, the db4o implementation is one of the better "lightweight" (meaning, smaller-scale/footprint) OODBMS's I've ever seen or used.
    Four, that Gavin chooses to make unqualified assertions in order to knock down the essay, without addressing the main points of either the original, or the follow-up, is hardly surprising or unexpected. (I had a much better discussion with Ayende, in the .NET space, over these very issues and points than I have ever had with Gavin. That discussion was recorded by .NET Rocks!, by the way, and when it goes online I will let the TSS folks know so they can blog or newspost it.)
    Five, contrary to what the flamers will say, the point of this discussion was to get people thinking about the issues, to shoot down dogma of any form, rather than try to suggest new dogma.
    Six, I find it ironic and/or somehow fitting that you, Cameron, are asking about corporate sponsorships. :-)


    Now, as the first-poser said, let the flaming continue....
  10. I do not, and will not, "evangelize" any particular technology, but I do, and will continue, to point out where technologies can be of use to programmers, particularly if they are technologies that are not commonly considered or known. The OODBMS is one such technology
    OODBMS were hyped for almost a decade (the 90ies). Dozens of books and hundreds, maybe thousands, of articles were produced, most of them declaring the superiority of OODBMS over "legacy" RDBMS. The hype collapsed because OODBMS could not prove theoretical or practical advantages - on the contrary.
  11. The hype collapsed because OODBMS could not prove theoretical or practical advantages - on the contrary.
    I've used OO dbs and also RDBM's extensively, and they both have different areas in which they excel. OO --> storing of complex graphs, fast navigation / traversal between objects, low impedance mismatch. RDBMS --> data independence, suitable for complex reports, much better schema management (DDL). Using an RDBMS for storage for a CAD system's diagrams, or an OODB for a reporting database is just asking for trouble. Andrew
  12. Casual Visitor writes:
    OODBMS were hyped for almost a decade (the 90ies). Dozens of books and hundreds, maybe thousands, of articles were produced, most of them declaring the superiority of OODBMS over "legacy" RDBMS. The hype collapsed because OODBMS could not prove theoretical or practical advantages - on the contrary.
    Basically I think it's a good thing if a hype collapsed in general. And perhaps even better for OODBMS in order to get a second chance because the 90th are far away and programming languages are a little more different these days. And if you look out there you can find a huge amount of clever papers (not only Teds) and books (and not only my books) that show the advantages of OODBMS in SPECIFIC areas! So it's more then logic that Andrew McVeigh cites what is the result of e.g. Pieter Van Zyl's ODBMS vs. RDBMS comparison:
    OO --> storing of complex graphs, fast navigation / traversal between objects, low impedance mismatch.
    RDBMS --> data independence, suitable for complex reports, much better schema management (DDL).
    I for myself will foster this discussion about the particular strengths of all persistence solutions (even not only RDBMS and ODBMS) by setting up an event about this topic in 2008. This might help that everyone has the complete portfolio of tools right at hand. Stefan Edlich (A lover of both RDBMS and ODBMS)
  13. And if you look out there you can find a huge amount of clever papers (not only Teds) and books (and not only my books) that show the advantages of OODBMS in SPECIFIC areas!
    This is an important clarification and restriction. (BTW, I attended your interesting db4o presentation last year.)
    I for myself will foster this discussion about the particular strengths of all persistence solutions (even not only RDBMS and ODBMS) by setting up an event about this topic in 2008. This might help that everyone has the complete portfolio of tools right at hand.

    Stefan Edlich
    (A lover of both RDBMS and ODBMS)
    Nitpicking: The 'First International Conference on Object Databases' was held long ago, see e.g. http://www.informatik.uni-trier.de/~ley/db/conf/dood/index.html
  14. And if you look out there you can find a huge amount of clever papers (not only Teds) and books (and not only my books) that show the advantages of OODBMS in SPECIFIC areas!

    This is an important clarification and restriction.
    That's the whole point of Ted's paper - there are OPTIONS for different use cases. There is not one silver bullet called ORM or ODBMS or whatever to solve the OR quagmire. Ted is very explicit to list 6 options and the trade-offs associated with it. Similarly, the message that we from the db4o project try to convey is that there is a class of OO persistence use cases, where ODBMS make more sense than RDBMS or ORM/RDBMS. Gavin & Co. are absolutely right, that RDBMS are great to confederate and abstract data from different applications into a common warehouse in an enterprise. I personally would fire my CIO if he was to introduce an ODBMS to replace an RDBMS for an ERP + PPS + etc. system. This nonsense proposal is exactly what broke the neck of the Versants, Objectivitys etc. of this world in the 90s - and we learned from that. Similarly I wouldn't think very highly of a product architect, if he was selecting an 2MB+ footprint RDBMS for a password manager to run on a cellphone with the argumentation that "RDBMS are the silver bullet for all my persistence needs," especially if the competition enjoys the performance, memory, deployability, 500K footprint and zero-admin benefits from db4o and consequently wins against our product in the marketplace. Even the most fervent TSS flamer will need to concede that ORMs simply don't run on cellphones, or are particularly optimized for shrink-wrapped software or distributed object caches in realtime SCADA systems, or to be used with JavaFX or Silverlight, to mention the latest client-centric OO technologies. Java and .NET developers need OO persistence there, too. Currently they often use roll-your-own, flat file, serizalization, and we give them an off-the-shelf product, so that they can work on value add coding rather than writing their own persistence layer. Christof db4objects, Inc.
  15. And if you look out there you can find a huge amount of clever papers (not only Teds) and books (and not only my books) that show the advantages of OODBMS in SPECIFIC areas!

    This is an important clarification and restriction.

    That's the whole point of Ted's paper - there are OPTIONS for different use cases. There is not one silver bullet called ORM or ODBMS or whatever to solve the OR quagmire. Ted is very explicit to list 6 options and the trade-offs associated with it.
    Similarly, the message that we from the db4o project try to convey is that there is a class of OO persistence use cases, where ODBMS make more sense than RDBMS or ORM/RDBMS.
    Gavin & Co. are absolutely right, that RDBMS are great to confederate and abstract data from different applications into a common warehouse in an enterprise. I personally would fire my CIO if he was to introduce an ODBMS to replace an RDBMS for an ERP + PPS + etc. system. This nonsense proposal is exactly what broke the neck of the Versants, Objectivitys etc. of this world in the 90s - and we learned from that.
    Similarly I wouldn't think very highly of a product architect, if he was selecting an 2MB+ footprint RDBMS for a password manager to run on a cellphone with the argumentation that "RDBMS are the silver bullet for all my persistence needs," especially if the competition enjoys the performance, memory, deployability, 500K footprint and zero-admin benefits from db4o and consequently wins against our product in the marketplace.
    Even the most fervent TSS flamer will need to concede that ORMs simply don't run on cellphones, or are particularly optimized for shrink-wrapped software or distributed object caches in realtime SCADA systems, or to be used with JavaFX or Silverlight, to mention the latest client-centric OO technologies. Java and .NET developers need OO persistence there, too. Currently they often use roll-your-own, flat file, serizalization, and we give them an off-the-shelf product, so that they can work on value add coding rather than writing their own persistence layer.
    Christof
    db4objects, Inc.
    Well, offering a better alternative to flat files and serialization is a whole lot different that solving the struggle as in: "For almost a full decade now, the Java community has struggled with the Object/Relational impedance mismatch, a fundamental problem for those who would seek to store rich domain objects into a relational database." Isnt it?
  16. To be honest I thought this was a fairly well understood problem these days. The thing to remember is that a "database" is addressing *two* primary needs 1) persistence and 2) location/lookup. Persistence is actually trivial in an OO language that supports serialisation especially where the dataset is essentially finite - just look at prevayler. No - the thing that determines whether we need a "database" is the question of how we locate the data we need, or in OO terms how we navigate to an object. The real impedence mismatch is not about mapping inheritance and suchlike, thats not really too hard to do, its about how we reconcile the OO need to encapsulate with the need to locate information using complex expressions and joins that need data to operate on outside the context of fully instantiated object. As I understant it db40 does some nifty byte code manipulation to alegidly provide the best of both worlds for certain classes of lookup criteria. However the more mundane approach of allowing back door SQL queries for location and from that point on dealing with java objects (a la hibernate) seems to work quite nicely in practice so long as those involved understand the nature of the inherent duality they are dealing with. This mundane approach also ties in quite nicely with Domain Driven Design which seeks to formalise this distiction between local object navigation (via explicit association/references) and object location using arbitrary complex criteria. All in all I just dont see that there is a big revolution waiting to happen and the technologies we have now work very well so long as those using them have a basic grounding in OO and relational theory. OODBMS solutions like db40 are interesting but I personally just dont see a paricularly big win to be had. Paul.
  17. The thing to remember is that a "database" is addressing *two* primary needs 1) persistence and 2) location/lookup.
    What about data integrity? I personally find it comforting when a database refuses to accept corrupt data, or refuses to perform an operation that would corrupt the data. What about transactions? I can easily persist things in flat files, and then do lookups in them. Pretty quickly, too. I don't need a "database" for that. I think a long time ago I wrote some perl scripts that did that.
  18. The thing to remember is that a "database" is addressing *two* primary needs 1) persistence and 2) location/lookup.


    What about data integrity?

    I personally find it comforting when a database refuses to accept corrupt data, or refuses to perform an operation that would corrupt the data.

    What about transactions?

    I can easily persist things in flat files, and then do lookups in them. Pretty quickly, too. I don't need a "database" for that. I think a long time ago I wrote some perl scripts that did that.
    Transactions are not relevent to this particular debate because both OODBS and RDBMS support them, although I concede it might be considered a primary requirement. Integrity is just asserts for data - you can just as easily add invarient checks to objects as you can constraints to a database. Paul.


  19. Well, offering a better alternative to flat files and serialization is a whole lot different that solving the struggle as in:

    "For almost a full decade now, the Java community has struggled with the Object/Relational impedance mismatch, a fundamental problem for those who would seek to store rich domain objects into a relational database."

    Isnt it?
    Those are Ted's words, not mine. And he is independant, after all :-) Seriously: I think Ted is right and you will concede that there's been a struggle. Why would a whole new product category -- ORMs -- emerge in the first place, if there wasn't a problem to fix? Or do ORMs provide any additional value other than being a bandaid for the O/R impedance mismatch? Christof db4objects, Inc.


  20. Well, offering a better alternative to flat files and serialization is a whole lot different that solving the struggle as in:

    "For almost a full decade now, the Java community has struggled with the Object/Relational impedance mismatch, a fundamental problem for those who would seek to store rich domain objects into a relational database."

    Isnt it?
    Those are Ted's words, not mine. And he is independant, after all :-) Seriously: I think Ted is right and you will concede that there's been a struggle. Why would a whole new product category -- ORMs -- emerge in the first place, if there wasn't a problem to fix? Or do ORMs provide any additional value other than being a bandaid for the O/R impedance mismatch? Christof
    db4objects, Inc.
    RDBMS have a solid foundation in mathematics and theory. They've also proven how well they handle change. Can OODBMS make the same claim? I have used object oriented DBMS in the past and find them useful, but over selling db4o gives me a bad taste. If I were to ever use an OODB, I would consider a different vendor first. I don't know if the hard sell works or not, but it definitely doesn't work for me. Just something to consider. peter


  21. Well, offering a better alternative to flat files and serialization is a whole lot different that solving the struggle as in:

    "For almost a full decade now, the Java community has struggled with the Object/Relational impedance mismatch, a fundamental problem for those who would seek to store rich domain objects into a relational database."

    Isnt it?


    Those are Ted's words, not mine. And he is independant, after all :-)

    Seriously:

    I think Ted is right and you will concede that there's been a struggle. Why would a whole new product category -- ORMs -- emerge in the first place, if there wasn't a problem to fix?

    Or do ORMs provide any additional value other than being a bandaid for the O/R impedance mismatch?

    Christof
    db4objects, Inc.
    The question is not of there is a problem - there is - the question is if OODBMS is the (complete) solution or not. ORM:s, on the other hand, "solves" the problem while still preserving the obvious strengths of the RDBMS.
  22. Re: Clarifications[ Go to top ]


    Six, I find it ironic and/or somehow fitting that you, Cameron, are asking about corporate sponsorships. :-)
    Now, as the first-poser said, let the flaming continue....
    I think Cameron's point is perfectly valid, and there are (usually) adequate standards of disclosure in most industries today, even including politics (in most countries :-). As an industry, we should follow those. Even MS-sponsored surveys usually indicate the link. Basically, it's expected that a speaker or writer discloses all commercial relationships with the product / company / area that he (or she) is speaking or writing about. It doesn't mean that the article will be necessarily biased, but it lets the reader know. It treats them with respect. The same topic has just been covered in a post on javalobby. As for Cameron, I've never seen him pretend not to be from Tangosol (or lately Oracle). Say what you want, but disclose any commercial interests, even those that have developed out of admiration for a particular product. Cheers, Andrew p.s. Ironic disclaimer -- I have no employee / consultancy relationship with any database company, OO or otherwise. I have purchased a competing product to db4o in the past.
  23. Re: Clarifications[ Go to top ]


    Six, I find it ironic and/or somehow fitting that you, Cameron, are asking about corporate sponsorships. :-)
    Now, as the first-poser said, let the flaming continue....

    I think Cameron's point is perfectly valid, and there are (usually) adequate standards of disclosure in most industries today, even including politics (in most countries :-). As an industry, we should follow those. Even MS-sponsored surveys usually indicate the link.

    Basically, it's expected that a speaker or writer discloses all commercial relationships with the product / company / area that he (or she) is speaking or writing about.

    It doesn't mean that the article will be necessarily biased, but it lets the reader know. It treats them with respect. The same topic has just been covered in a post on javalobby.

    As for Cameron, I've never seen him pretend not to be from Tangosol (or lately Oracle). Say what you want, but disclose any commercial interests, even those that have developed out of admiration for a particular product.

    Cheers,
    Andrew
    p.s. Ironic disclaimer -- I have no employee / consultancy relationship with any database company, OO or otherwise. I have purchased a competing product to db4o in the past.
    No offense to Cameron was intended; that doesn't prevent me from teasing Cameron about being a sellout, however. :-)
    Your point is valid, however, and that's why the end of the paper very clearly states that this is a "sponsored" paper by db4objects and the odmg.org portal.
  24. Re: Clarifications[ Go to top ]

    I dont think it would be logical to store objects in the DB. It makes sense to store Data in the DB, which will be used by different Objects in the way the application is interested. So, the stress of a DB should be data retrieval and storage, rather than Object storage. Just because those objects also contain data, doesnt mean that you should store the entire objects. So, for me, my need is always a mechanism to store Data and its relationships, i.e. RDBMS is what I need. However, to get my data into processing state, I need something to convert it into a Object based state, which is the purpose of ORMs. So, what should be a good solution is: RDBMS --> ORM --> Domain Objects --> Processing logic. e.g., books may or may not be a part of library. In above example, Data is book, library and, if existing, any association. Now, how do I retrieve the data, i.e. only through retrieve books associated to libraries or retrieve books independently is the need of the application. So, what makes sense is to store data, and their relationships only. There is no reason to complicate it by storing in form of Objects as long as my abstraction layer of ORM can give me processable data.
  25. Re: Clarifications[ Go to top ]

    'Tis a fair question, Cam. Let me set the record straight.
    Thank you, Ted. That's exactly what was needed. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  26. Re: Clarifications[ Go to top ]

    Tangosol Coherence: The Java Data Grid
    Just FYI, your new link (http://www.tangosol.com/) is far less informative than your older page: http://web.archive.org/web/20060424185614/http://www.tangosol.com/. There's nothing about your product on the new page. Don't let them portalize you! Products tend to get hidden in big corps.
  27. It, like his recent Tech Talk with TSS, focuses on Db4o ..


    OK, I am really uncomfortable pointing this out myself, but for the second time (i.e. the second article on this subject on TSS) I missed the part of the post where it explains the relationship between Db4o and Ted. Ted is an independent consultant
    Independent ? What does it means ?
    , and is not an employee of Db4o, but that makes it even more important to point out that he is working for Db4o (precisely because it's not self-evident).

    If you don't point it out, it makes Ted look bad, and it makes TSS look like just another sleazy "pay for play" site.

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
    I think that the whole story could have accomplished with a few links to Scott Ambler writings and DB40 manuals. Saving some disk space somewhere. Without recalling a big tragedy. Guido. P.S. Better having a beer talking about sex.
  28. ...Ted is an independent consultant

    Independent ?
    What does it means ?...
    It denotes someone working for a separate company that offers consulting or contracting services to other companies. It's an often used phrase. It isn't necessarily synonymous with "objective" or "unbiased". That's not what it is referring to... Andrew
  29. ...Ted is an independent consultant

    Independent ?
    What does it means ?...

    It denotes someone working for a separate company that offers consulting or contracting services to other companies.
    And this is what is normally called (at least here !) a consultant. With no further qualification.
    It's an often used phrase.

    It isn't necessarily synonymous with "objective" or "unbiased". That's not what it is referring to...

    Andrew
    Saying independent gives the impression to be (I apologize for the rude form): "not payed to say the things he/she says". Guido
  30. The notion of the domain model as the one and only schema doesn't have to mean your using an OO database. Berkeley DB Java Edition is cool and used in Tangesol correct? They are calling it DPL (Direct Persistence layer) http://www.oracle.com/database/berkeley-db/je/index.html. I spent a lot of time talking to the Berkeley guy at JavaOne at the Oracle booth, I think many of us will find it useful especially with the latest version supporting schema evolution gracefully. I'm very interested in having an Application Database based on something like a direct persistence layer DB40 berkley etc... , but then have my domain model export itself nightly to a datawarehouse for reporting purposes. If you have a database schema that 'is the single source of truth, it is god' then embrace it rather than ignore that business reality. Something more like what neal ford http://www.nealford.com/ is doing with groovy and ibatis to essentially generate the domain model and ibatis mapping files from the database schema using groovy makes a compelling case, rather than OO Mapping with JPA oriented approaches, especially if your just end up with an anemic domain model anyway (row to object style that many folks end up producing as a 'domain model' when handed an existing dbms schema. -Brian
  31. ...I'm very interested in having an Application Database based on something like a direct persistence layer DB40 berkley etc... , but then have my domain model export itself nightly to a datawarehouse for reporting purposes.

    If you have a database schema that 'is the single source of truth, it is god' then embrace it rather than ignore that business reality.[...]
    -Brian
    It's precisely because of usecases like this that db4o provides a replication system (dRS) to replicate data to/from relational DBs (and between db4o instances too). This way you're not isolated from the rest of the world. German
  32. I enjoy the discussion...but[ Go to top ]

    Ive been there fighting the RDBMS vs ORM, vs OODBMS battle on more than one occasion, and there's nothing new in what this article says and his first article stating the problem was a lot more intriguing than his SQL (read sequel). If I were to reflect on his first articles title, "The Vietnam of Computer Science" I would have to sit back and say, "Where are the computer scientists anyway? (in Canada?)" The technical reflections of many a fine engineer are not the same as computer science. Computer "Scientists" are not truly interested in this problem. The software engineers writing apps on a daily basis ARE interested. If science had much to do with it, I truly believe SQL would have been superseded by now by something much more interesting and ORM would be probably not even a topic of discussion. This isnt computer "science" it's computer confusion.
  33. Hey wheres the Cocobase Guy?[ Go to top ]

    Cocobase guy?? you out there?
  34. naw dude I gotta better one...[ Go to top ]

    Wait for it... Wait... The first guy that wrote a program in an OO language had to deal with "impedance mismatch".... And so will the last! Guffaaaaaaaaaaaaaaawwww!
  35. "dual schema" is great![ Go to top ]

    "dual schema" separates long-lived persistence structures from short-lived OO designs (the latter being constantly refactored by sedulous Agile programmers, so I've heard). Moreover, the long-lived persistence structures have multiple clients: applications (written OO or not), report generators, DWHs, batch programs ... They all are best served by a stable, thoroughly designed RDB in 3rd normal form.
  36. Re: "dual schema" is great![ Go to top ]

    "dual schema" separates long-lived persistence structures from short-lived OO designs (the latter being constantly refactored by sedulous Agile programmers, so I've heard).
    Moreover, the long-lived persistence structures have multiple clients: applications (written OO or not), report generators, DWHs, batch programs ... They all are best served by a stable, thoroughly designed RDB in 3rd normal form.
    Not to mention the fact that you can teach a monkey basic SQL in 3 hours.
  37. Re: "dual schema" is great![ Go to top ]

    "dual schema" separates long-lived persistence structures from short-lived OO designs (the latter being constantly refactored by sedulous Agile programmers, so I've heard).
    Moreover, the long-lived persistence structures have multiple clients: applications (written OO or not), report generators, DWHs, batch programs ... They all are best served by a stable, thoroughly designed RDB in 3rd normal form.
    In the article Ted Neward notes that if the database is a point of integration, then the RDBMS/SQL approach makes sense. It's only when the database is being slaved to the code that the OODBMS would be useful. To me this answers the question "where do I put my umpteen terabytes of data that must (by law) be retained for at least a decade such that non-programmer power-users can write reports and and analyze it?" OODBMS is not (IMO) the answer to that question and I don't think Ted is saying that it is either.
  38. ORM SQL impedance[ Go to top ]

    is an old thing. In C# there is more stored procs possibly, possibly Java folk are un-sure if SQL access is the slow part or how/where to solve it. If ORM is slow, you can add more memory and cache it more to avoid the db engine. Tuning the query is another way (star join ex_ A big part of J2EE reputation is the over-reliance on ORM. If there are 2 camps then.... one say SQL is not more important, and another that says it is more important. There are sql centric DAO (iBatis and a few others) and ORM centric DAO (hibernate)depending on if you have sql/stored proc experience or not. No secret that I use iBatis to solve the impedance mismatch and pick best of both worlds. .V
  39. ORM is for developers who don't know how to make a good DAO layer. OODBMS is for geeks who have grown tired of linux. RDBMS will never be replaced.
  40. ORM is for developers who don't know how to make a good DAO layer.
    This nonsense. To me a good DAO Layer looks lightyears better when using objects transparently with JPA or Hibernate then using non ORM (as pure SQL).
    OODBMS is for geeks who have grown tired of linux.
    My old school teacher once told me: "You are connecting tomatoes with trains." One beer for everyone who sees a connection here ;-)
    RDBMS will never be replaced.
    And this is exactly the point: You can make ODBMS and RDBMS enemies with such sentences. Is this (replacement) our goal? Do we love more flames between them? Frankly, advanced developers or architects have zero intention to replace RDMBS with ODBMS. RDBMS and ORMs are really great and mature. Annotating, querying and using your domain model with Hibernate,JPA etc. is really fun and powerful. Nobody wishes to replace this in the enterprise space. It's about knowing the complete space. And ODBMS serve a good purpose in the space as XML Databases and other persistence solutions do. Stefan
  41. Frankly, advanced developers or architects have zero intention to replace RDMBS with ODBMS. RDBMS and ORMs are really great and mature. Annotating, querying and using your domain model with Hibernate,JPA etc. is really fun and powerful. Nobody wishes to replace this in the enterprise space.
    Nobody in the enterprise space wants to overcome the object/relational impedence mismatch. They just want to throw layer-upon-layer of stuff on it so that it can't be seen. That's very sad if it is true. Why can't we learn from what we have so that maybe tomorrow we'll have something better?
  42. JDO helps here (again)[ Go to top ]

    Disclaimer: I was/am on the JDO & JPA expert groups. It's worth noting here that JPOX is writing a JDO front-end for db4o. This would allow you to compare with the same codebase (native queries aside) the performance of ORMs and OODBs without recompilation (once they're done). Ted, wouldn't that be interesting? The only Java technology that's mature and standardized that provides for even the possibility of such a comparison is JDO. [Deep sigh] Ok, I'm sure we'll now hear from the haters... -matthew
  43. Re: JDO helps here (again)[ Go to top ]

    ...The only Java technology that's mature and standardized that provides for even the possibility of such a comparison is JDO.

    [Deep sigh] Ok, I'm sure we'll now hear from the haters...

    -matthew
    I agree wholeheartedly with this sentiment. I have used JDO extensively (mainly for OODBMS work) and I found it to be excellent in performance with a strong architecture and clearly defined object lifecycles. I can't understand why it hasn't prospered, apart from vested interests in existing technologies... Andrew
  44. The issue can be fixed by upgrading to "The Iraq of Computer Science"
  45. It does you no favours using the Vietnam war as an analogy in making a point about any aspect of computer science. Try re-naming your articles. After all I am sure from a Vietnamese point of view the 'quagmire' was a total success.
  46. It does you no favours using the Vietnam war as an analogy in making a point about any aspect of computer science. Try re-naming your articles. After all I am sure from a Vietnamese point of view the 'quagmire' was a total success.
    No, not really. The Vietnamese people suffered far, far worse in the Vietnam War (and I apologize to any from Vietnam who know the war by a different name, I've only heard the American name for it). They lost far more than we did, by just about any measure you care to name. And besides which, the analogy is from the US's point of view. All analogies break down at some point. The point of the analogy is simple: the US thought they could "handle" the murky nature of a conflict in Vietnam, they thought they were handling it, and then they found themselves in a mess that they couldn't solve and couldn't get out of easily. That, by whatever analogy you care to use, is a quagmire. Would people be less offended if I called it "O/R-M is the Russian Afghanistan of Computer Science"?