Are Rdbmss Dead

Re :"Are Relational Database Management Systems Dead?"

Discussion moved from ZombieTechnologies, where it's claimed that Relational Database Management Systems are an "older technology" and Could you expand on why LotusNotes helps here? It avoids the concurrency problem basically by OptimisticConcurrency, and leaving the humans to clean up the mess afterwards (there's basically zero support for resolving replication conflicts). I happen to agree with this approach for the domains that Notes is used in, but I wouldn't call it a generically better technique. -- PaulHudson

They are just not "sexy", but continue to be work-horses of IT with no sign of anything threatening their position as "domain fact engines" right now.

To me, in the long run, the data wins out over the algorithms. What I did with my customer data in 1979 is probably no longer relevant. That customer data might well still have value. -- PaulHudson

This strikes me as an aptly formulated and nicely pragmatic observation. However...

The problem is that you can't defend this claim without also defending its converse - namely, that the value of what you do with the data today is less than the value of the data itself in twenty years' time. I would suggest that this is obviously wrong, on the grounds that if you aren't efficient today in what you do with the data, you won't be around any longer in twenty years' time.

But the statement says nothing about the relative values of the data and what you do with it now. It just says that in the long run, the data still has some value. What you did with it years ago probably doesn't. So your converse isn't.

Let's drop the converse, then. Paul is suggesting that because twenty-year-old data is worth more than twenty-year-old processes, it is wiser to invest in making sure today's data will keep for twenty years than in making sure today's processes are well suited to today's needs. I think this is indefensible, on the same grounds as I present above.

Although I probably exaggerate in the presentation of the idea above, I do believe the idea is correct. Two ways of implementing something:

embedding the data in a program that supports today's way of processing the data 
        (and to me, this is what working with an OODBMS is - the database inherently reflects
        the way you will use the data)
Processing is very efficient.
use of the data in unforeseen ways is difficult (this is why there are no decent report
        generators for OODBMS)

or:

putting the data in something very flexible from the point of view of retrieval
writing a rather more disconnected program to work with that data
the "impedance mismatch" means processing is less efficient
But I have more convenient access when I need to use the data in some unexpected way
        (and this, in my experience, is nearly always needed)

Now of course, both data retrieval and processes need to be efficient enough for today's processes. But I don't think that means one has to use an OODBMS to ensure that, and I believe the need to remain flexible is indeed often a good reason for choosing a RDBMS instead.

In other words, I think what you present is perhaps false dichotomy - it's not a stark choice between good processes or good data, or investment in one totally at the expense of the other (my over stark presentation of the reverse is probably as misleading). Just that sometimes, a longer term view of the data should lead you to less than optimal-today process.

Even changing in relatively minor ways how you use the data in a OODBMS seems difficult to me (although as I said up above, I don't know a lot about real-world OODBMS - how do they handle SchemaEvolutionInOodbms nowadays?) -- PaulHudson

It is my opinion that if you organize the data as facts or information regarding "things" (entities), follow OnceAndOnlyOnce, and disregard how it is actually used in a specific application other than having necessary references (keys), then it will naturally gravitate toward a relational-like design. Competing DB paradigms tend to design data structures/patterns around specific application needs. This is the biggest difference between database paradigms in my observation. Relational takes a longer-term view, for good or bad.

On the matter of long term corporate strategy, here is an interesting link: [http://mckinseyquarterly.com/article_abstract.asp?tk=59494:1076:21&ar=1076&L2=21&L3=34] Creative Destruction: Why Companies That Are Built to Last Underperform the Market-and How to Successfully Transform Them ISBN 0385501331

It should be noted that Microsoft's COM+ and .Net initiatives are decisively oriented towards RDBMS. I have no figures but my guess would be that behind basic file system there is more data stored in RDBMS than anything else out there. My guess is that the growth of RDBMS is huge with the internet. Does anyone have figures?

I think that ultimately relational databases are definitely not dead and are very sophisticated. I think the "impedance mismatch" is more about languages than paradigms... there needs to be better marriage between set/relation manipulation and normal imperative languages. GemStone did a good job of this by leveraging the SmalltalkLanguage collection framework (they could analyze boolean query blocks and leverage indices for the query.)

But to claim that data is more important than process is wrong. Certainly, data is important, but process provides context on how to create value out of the data. More sophisticated software process systems are an economic imperative... as software comes to encode more knowledge and to automate / assist more rote processes, it frees up professionals to do more creative / innovative work. -- StuCharlton

I still claim data is pre-eminent, and I think the statement process provides context on how to create value out of the data actually is a demonstration of that. Data with a different process still does something useful. The same process with different data often does not -- PaulHudson (overglib, but you see what I mean, I hope).

From Reuters: While older database systems -- including object databases designed to store multiple data types, like sound and image, as opposed to just text - suffered negative growth in 2000, the newer database management systems grew 15 percent and accounted for 80 percent of the total database market, Gartner said.

So where can we get FreeSoftware OODBMSs? I just stumbled upon http://www.pocketdb.tv/Default.asp which describes itself as both.

See ObjectOrientedDatabase.

I think relational databases are a good example of DoTheSimplestThingThatCouldPossiblyWork. A set of records with fields is simple. SQL isn't necessarily a good thing, but it is still easier to use than the OODBMSes I've tried. -- KrisJohnson

I agree that SQL is not the best a relational query language can be. Chris Date, for one, is known to complain. A language called BS-12 from the early 1970's is sometimes considered superior to SQL, partly because it relies less on syntax nesting, using references instead (or in addition to), which make section reuse easier and can break things into cleaner sections IMO.

The Ingres/Postgres project originally had their own query language that was considered by many to be superior to SQL (it certainly used a better set of guiding design principles, regardless of what one thinks about the results). They gave up and used SQL in the end, though, because ThatsWhatPeopleWanted?.

See SqlFlaws, RelationalLanguage

Is there a JDBC/ODBC for OO databases? If not how could you possibly risk the lock-in with one vendor?

Well, that's the rub. OODBMSes are sufficiently different from each other that you pretty much have to select one and lock yourself in. That problem was supposed to be solved by the ObjectDatabaseManagementGroup?, but I think that organization is basically defunct and its output largely ignored. Although I hear it's kind of coming back as the JavaDataObjects specification (http://jcp.org/jsr/detail/12.jsp). -- RandyStafford

See http://synthesis.ipi.ac.ru/synthesis/publications/oodbbet/oodbbet.ps for a start at formalizing the mathematical basis for OODB's.

[CategoryDatabase - relational DB discussion]