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

5 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 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 Unknown, at 5:43 AM  

Post a Comment

<< Home