The Softer Blog

2005-01-30

Database Atrophy

Welcome, :)

I feel we, the software development community in general, are suffering from a condition called "database atrophy" and most of us don't know it.

We are so dependent on the services our relational database servers (RDBMS) provide, that many of us could not live without them.




I believe this RDBMS dominance is causing us to yield but a fraction of the power in our computers.

Object-oriented languages have been around for decades and the next few years, at least, will clearly be OO language dominated. There is no serious contending platform besides Java and .NET today.

Still, the promises of OO, such as high-quality and reuse, are not fulfilled.

As an industry, we are still holding conferences on how to better develop CRUD software and hailing thing like Ruby on Rails.

And the reason for that is RDBMS dominance. There is absolutely no way of doing OO with your live data in an RDBMS.

In contrast, there is a specific breed of aliens on our planet that develops systems of complexity, performance, stability and portability that completely dwarf our efforts, and for a single reason:

Except for storing keyboard control settings and high-scores, they are completely free from databases.

10 years ago, people thought using "data-aware" GUI "objects" coupled to their database was using OO. Today, many people think that using an Object-Relational Mapping (ORM) tool to map dumb data-objects to database records, is using OO. :(

ORMs such as Hibernate, Castor and Toplink are central players in this depressing context of ours. On the one hand, they provide a palliative in the absence of true OO but, on the other, they actually hamper the community by illuding it and giving OO a bad name.

But I believe a brighter future is inevitable:
  • OO design patterns are starting to kick in.
  • IDEs are starting to invest in decent OO design support rather than database-coupled "RAD" development.
  • Open source project are cross-pollinating best OO techniques such as refactoring, test driven development, implementation independence, etc.
Feel free to participate.

This blog is dedicated to denouncing the symptoms and causes of database atrophy and providing a vision of what we can do in full health. :)

See you, Klaus.
"Do You Still Use a Database?" http://www.prevayler.org

6 Comments:

  • okay Richard Mansfield has been added to my reading list's .cvsignore--what a bunch of rhetoric. anyway, most of my clients are very much fans of OO, even though they don't really know why. but as expected, they are even bigger fans of RDBMS. many of them are interested in, or are already using, ORM. i have had many conversations with the archtectual staff at these companies about Prevayler (and similar projects) always with the same result. "Hmmm that's really neat, but it wouldn't work here." to which, of course, i ask, "why not?" and for each "reasonable" issue raised, i can sucessfully remove their skepticism, except one. the response goes something like this. "we need to be able to use [insert reporting tool here] to generate our reports from the database. how do we use [reporting tool] to connect to Prevayler without rewritting our reports?" to which i say, "you can't. see, won't work here", they respond. now take this example and expand it to all the other needs of enterprise systems. most architects feels that the only way to get apps to share data is through a database :( i loved to hear the result of some of your musings about this topic.

    btw, this blog is a good idea. i often need places to rail against technologies long over due for retirement. now i have another one :)

    By Blogger Mike Sandman, at 3:53 AM  

  • Several points:
    1. I'd argue that COBOL is a major development platform as well, albeit one where the work is mostly the evolution of an existing system instead of brand new development.
    2. Another reason why many organizations won't move away from RDBMs is that they have a huge investment (money, people, political) that they're not willing to lose.
    3. Data professionals and object developers need to work closely together. This will help to cross-polinate ideas. Both groups have very good knowledge and experience which the other can benefit from.
    4. Many of you will find www.agiledata.org to be interesting.

    - Scott Ambler
    www.ambysoft.com/scottAmbler.html

    By Anonymous Anonymous, at 8:58 AM  

  • Scott--

    2. Another reason why many organizations won't move away from RDBMs is that they have a huge investment (money, people, political) that they're not willing to lose.I agree it does not always make sense to use object persistence in serverside data warehouses. Not only for the legacy but because many apps use one DBMS, and they usually don't share the same object model. So tables really are the smallest common denominator.

    But if you think clientside you'll see a huge opportunity to keep objects persistent, every time a server connection is not guaranteed, like in a mobile device, a car, a medical device, a robot, a measurement device, a packaged piece of software. Why would I use a whole stack of ORM and RDBMS just to keep objects persistent? Tools that are designed to see DBAs taking care of them - which you don't have clientside. I don't run Crystal reports on my PDA, do you?

    What we ask for is the acknowledgement that "database = RDBMS" is just Plain Old Thinking (POT), and that there are non-trivial use cases where object databases are the right way to go.


    3. Data professionals and object developers need to work closely together. This will help to cross-polinate ideas. Both groups have very good knowledge and experience which the other can benefit from.Absolutely.

    Christof

    By Blogger Christof Wittig, at 10:21 PM  

  • "I agree it does not always make sense to use object persistence in serverside data warehouses. Not only for the legacy but because many apps use one DBMS, and they usually don't share the same object model. So tables really are the smallest common denominator."


    Maybe I am to visionary , but I am working on changing this by simply having the smallest dominator to be the class !

    I just love the idea to ONLY think in objects and I do believe it gives an enormous power of possibilities when started from the lowest persistence level. I am only afraid that the OODBMS technology is not ready for this yet ! I do have the first version of my product running, its a truly object based. ERP/CRM/BPM and (in the future)whatever you can imagine web based product. Imagine having ONE ROOT Company object and you can traverse the whole General Motors from it ! You can even very simple have a mind map drawn from this. It might sound sick, but in general it works. THE TWO MAJOR problems I face, and which I do believe are a major reason why OODBMS are not more successful, are Garbage Collection and Huge Collections.

    Great efforts are made to have persistence completely transparent and included in the programming language, see the new native queries coming up in db40. While we finally don't have to think of memory leaks and null pointers, we introduced that old fashioned problems again in ODBMS. Surprisingly it seems always only me to see this as a major problem, and I suspect this is due to the reason that most people using ODBMS using it for very well defined applications which don't change. Like Cristof mentioned, in the enterprise world “many apps use one DBMS”. In these cases the DBMS has NO CLUE what the apps do with the data, so its not the DBMS responsibility when data should be deleted.

    Using ODBMS this is a total different story. Having references everywhere chaos starts quickly if the ODBMS does not handle reference changes. I don't see ANY product out there which has solved that issue !

    Second problem are huge collections. In the RDBMS world I query for what I need, so it does not matter how big my collections are. With an ODBMS performance goes quickly down to a level where the whole application just stops working if objects do have huge collections. Of course one can query just for the objects in the collection, but this in many cases does not only violate encapsulation it also goes against the OO principle !

    I would be very grateful if anyone of you smart developers can comment on this ! After all work I have done so far and experience of USING my (still very very simple) application I am afraid that this whole OODBM is not feasible until the above mentioned problems are solved . Maybe we have to even change the way we use objects to reflect the persistence problems.

    Joe Robe

    By Blogger joe, at 1:04 PM  

  • I totally agree with Klaus.

    --Diego Alvaro Pereira

    By Anonymous Anonymous, at 3:02 PM  

  • Have you heard of acid-state? It's a persistence library built around the functional paradigm.

    It has a bit of a following in the Haskell community, owing to its simplicity and performance.

    By Blogger Chris Wong, at 5:43 AM  

Post a Comment

<< Home