You’re right about solid-state drives, but I’m pretty confident we’ll be seeing these problems solved in short order and solid state drives becoming very viable. But you’re right, as it currently stands, they’re not sufficient.

I also agree that the relational model has proven itself time and time again for the best way to store and retrieve data that involves a slower permanent storage mechanism behind the database engine (i.e. disks, SAN, etc). My point is this: If everything is already in memory, is the relational model the best model for representing data in a high-speed storage mechanism (i.e. RAM)? Especially when you consider that our applications are object-oriented and we’re spending a lot of effort and pain dealing with Object/Relational mapping concerns?

I’m not saying get rid of reltional, I’m saying, don’t use relational in an in-memory situation JUST BECAUSE that’s we’ve used in the past and that’s what we know. If, in fact, it turns out that the relational structure still proves itself in an in-memory-only situation, then great, we’ll keep using it. But we should all be aware the reasons WHY we’re using the relational model in those circumstances.

I think object databases are getting there, but you’re right, I still don’t think they can compete in the large DB realm. But for databases that large, you’re probably not talking about a lot of OLTP stuff, you’re probably housing a lot of historical data for reporting or “you might also like these products”-type stuff, right? I don’t think that even EBay’s active auction table data pushes past a few dozen GB. It’s all the other historical data (user history, user ratings, etc, etc, etc).

In an O-O world, it would probably make sense to only have the active domain objects in the ODB and push the historical data into a separate relational model for querying and large data storage using disks/SAN, etc.

I believe the DBMS market is going to change significantly in the coming years, but I believe some of your facts are incorrect and this is leading you to faulty conclusions.

First, a large percentage of databases are growing at a rate of 10′s gigabytes – terabytes per day. Within a very short period of time it is no longer possible to cache everything in RAM. Placing large percentages of databases in RAM has been successfully done for years, but over the last few years the percentage that many organizations can put into RAM has dropped to a low percentage. So, while you conclude that it is more possible I conclude that it is less possible.

Second, the relational model has been proven superior to network or hierarchical models for a couple of decades now. There have been numerous challenges over the years, but no sustainable superior alternatives have been developed. It is interesting that the relational alternatives attack on the small databases, but that is exactly the wrong place. The small database problem is no longer interesting to most vendors, database researchers, and organizations. Solving the large database problem is where the focus is now and anything under 100 GB is considered small. The biggest problem facing the relational model is the 10+ TB databases. Relational models do very well on the low end, but completely fall apart on the high end. It will be the inability of RDBMS’s to scale on the high end that will have more impact on the database market than non-relational or in-memory alternatives on the low end.

Third, solid-state drives aren’t close to being ready for the mass market. Heavily used databases can wear out a solid-state drive in a couple of months. The organizations that need them the most can’t afford them due to their high cost and short life span. I’m sure this will get better over time, but solid-state is somewhat overhyped right now.

What I struggle with and don’t have an answer for yet is what to do about the high end. Let’s assume we eliminate relational or come up with an O-O solution that everyone is happy with on the low end. It is not clear to me that O-O is going to do any better on the high end. I don’t know of anyone working on a high end database (250+ TB) that is considering an object model. Many of them have rejected a pure relational model, but still rely on some relational technology. So, if they aren’t going to use an object model then there will have to be some mapping.

Part of my point was that when everything is in memory, how the data is arranged internally is not my concern. When everything is in memory, you could even have several different views/presentations of the data (objects, JSON, Relational, XML etc).

I guess I’m wishing that we could separate the means of querying/accessing the data (SQL + Relational) from the Storage (Relational).

Right not this isn’t very easy because the RDBMS mindset is still heavily disk/file/storage-based thinking when is doesn’t really need to be any more.

I agree with you in principle, but in practical, the RDBMS is going to be around for a long time. Companies have made significant investements in hardware, software, and human resources for an RDBMS strategy, and they will be loathe to toss that aside.

I’d be first in line to go another route for my dead object storage for sure, but as an industry we aren’t there yet. Given that, maybe ORM should start gearing up to be the Iraq of computer science. There’s no end in sight and no easy way out.

RDBMS do what they do very well. I don’t really see them going away for a long, long time.

But now that I think about it, it depends on the volume of data and type of processing. If we’re talking thousands of records with heavy processing going from one model to another, some DDD concepts would actually benefit you.

If we’re talking millions of rows and little processing, then no DDD.

Millions of rows and heavy processing? Maybe.

I think mostly about line-of-business applications and stuff that involves a lot of users creating/retrieving/updating things and list of things with validation, etc. Looking back at the ones before my DDD days, I can’t think a single one that wouldn’t have benefited from DDD.