You are kidding, right? Is this based on any actual facts, or just wishful thinking?

Claiming that data-centric design is dead is about as accurate as claiming that C is dead. Yes, the ‘cool crowd’ loves to talk about the alternatives, but the reality is that it it will probably outlast us all.

For example, in applications with non-trivial perf or scale requirements, the bottleneck is usually in the data layer (since that is where the state is, that is where the mechanical moving parts are, that is the layer which doesn’t easily scale horizontally, etc). Designs must naturally adapt to address those bottlenecks, which results in the data-centric view where storage constraints such as index sort orders or sproc signatures can bubble up into the domain model or even the UI.

Using nice clean patterns such as DDD is “nice”, but is very hard to justify when the investment in hardware dwarfs the cost of development & maintenance (think facebook or amazon).

The four of you reading this who work on amazon.com and facebook.com get a free pass for your data-centric views. Congratulations. Anybody know what facebook uses for its data storage solutions?

Hardware costs dwarf costs of development maintenance? Again, the 6 of you who work in such an exotic environment where this is actually true can go as well. The rest of you who think your 7 TB storage solution Oracle represents costs vs. a roomfull of jr and sr developers…well, there are actual facts available for that.

I never claimed that data centric design is dead. Just that alternatives won’t get a fair examination until those DBAs all retire. Big difference. Note that I’m not even stating that object-first (or whatever) is the One True Path. Maybe its not for a given situation, who knows.

my comment was munged up, forgot to deal with the greater than sign, oops. replace “greater than 7 TB storage solution oracle” with “freakishly big ENTERPRISE data system”.

[...] Elegant Code asks “What’s the next big shift,the one you’ll never see coming” [...]

I have yet to see an ORM tool that procedures efficient SQL at the database. I doubt this will ever be possible due to the fact that SQL deals with set operations and OOP deals with instances of things; it’s hard to marry a data layer that works on the many with a object model that works with instances.

Since the bottle neck in most applications is the storage layer (be it big-table or the traditional RDMS) it seems highly pre-mature to suggest that the Data-Centric view is consigned to the history books.

In fact, due to the increased latency involved when doing stuff on the web, I would argue that the data-centric view has increased in importance. People want pages faster than ever before and to do this they need the fatester performing applications, which in turn requires faster data operations.

The only way to get this increased performance is to make the database do less – and that requires less OOP and more data centric code.

NHibernate produces great performing SQL in all the traditional situations. Add in basic caching, also provided by NHibernate, and you’ve got a solution that is more than good enough for web apps. Plenty of others have researched this and posted results, available via google.

Could you hand-craft your SQL to provide the most performant solution? Well, of course! And if you want to pay programmers to sit around worrying about that last microsecond, then I guess it’s your money…

Any extra time spent hitting the database is utterly dwarfed by the time spent transmitting your data over the wire to the brower, and then waiting for the browser to render that data. It’s not even close.

Fundamentally, if you want faster web pages, transmit less data.

But, you’re missing the point: you’re still looking backwards. I’m not saying that data-centric is consigned to the history books. I’m asking, what is it that we’re missing now that will be the great flamewars of the next 5 years?

There’s this thing about data. It stays. We are constantly finding new things to do with the existing data we have. OO, for example, is very good at writing the program we want today, but it gets painful when the information we want to manipulate in a new way is “trapped” inside a domain model that’s optimized for specific behavior.

As such, it’s no surprise that the data centric mindset exists, or that it continues to exist. The data is where the real value is in most systems, and ignoring that gets you in a lot of trouble eventually.

I’m not sure I get what this post is about. “Data” isn’t going anywhere, and I don’t believe “data-centric design” has anything to do with DBAs. I’ve worked on plenty of projects, data-centric and otherwise and I’ve never had a DBA hovering over my shoulder directing me as to how the software should be designed.

Applications are the link between data and users. Data is a link between applications. You can’t really justify one without the other. I’m not really sure who you’re trying to blame for holding you back. Sure there’s new approaches and technologies coming up every day, and regardless of what the “old guard” might argue, it’s *your* job to justify *why* the next new thing should be used. It might feel that there’s a lot of resistance, and the focus is to “do things the way that they’ve always been done.” But the simple fact is that this “old guard” put in the time and sweat to justify that back then, those new-fangled concepts were worth it. Respect that, because jumping off a cliff with a new “shiny thing” that’s supposed to let you fly will have disasterous consequences if you forgot to read the instructions first.

@Chris: Who said anything about “trapping your data?” For that matter, where did I state that the data has no value? Assuming that by “manipulate in a new way” you mean some sort of reporting – why not either use a reporting system for that, or if we’re talking about real analysis, use OLAP instead of trying to make the OO Transactional system do both? But perhaps I’m not understanding your comment.

@Steve: Not having to deal with DBAs telling you how to code: man, you are so lucky As far as justifying the new shiny things: __bring it on!__ I think that’s great. Let’s have rational discussion based on facts, rather than the typical response to something new: “Change Is Scary.”

@Steve: and to make sure I understand you: are you implying that the Old Guard should be “respected” because of their time served?

Respected for their experience, yes. Unfortunately, a stereotype of the “old guard” is that they’re stuborn. I believe the fact is that there isn’t enough respect for the art and this makes developers (DB or otherwise)very defensive. Too much of “well that might be how you *used* to need to do things, but just stand back and watch how we do things *now*.”

Yeah, there are going to be lots of people out there that have arrogance and ignorance to spare. “This is the way I’ve always done it and I ain’t about to change until, or even if you prove I’m falible.” But that just as equally applies to new developers as it does “old school” ones.

Opening you mind, and ears to experience *and* new ideas leads to brilliant things. Typically this is best accomplished by first shutting one’s mouth.

@Steve: Respected for experience, absolutely. But Years In The Job does not necessarily equal “Experience,” like that old saw about “15 years of service, the same year of experience 15 times..”

And yes, not all new ideas are good. Not all old ideas are bad. I’m not advocating something crazy like that. I suspect we’re both saying the same things just from two viewpoints…

So, lets have the Old Guard and the Brash Young Lions quit bickering about databases, and reconsider: What worthwhile, valid, awesome, New Thing are we all missing out on that the New Young Lions are going to use to steal our jobs and force us into Management or Non-Coding-Architecture positions?

Is it ever too late to adapt with the times, find value in The Latest Thing, and join the New Young Lions and their technology?