A vendor provided solution (which is necessary for our business) requires an SQL server to run, but it no way maxes out that machines capacity.  We already had to buy the license, so why not use it for other things?  We already have to pay someone to administrate the system, why not leverage him for multiple solutions?

Performing the analysis couldn't hurt, but it would most likely be a waste of time as we have neither infinite money nor infinite time.  Very few business decisions are made on what's best technically, rather a combination of what's affordable, what do we already have, what can we leverage, and what will WORK (technically) rather than what is best.  This is made apparent by the sheer number of businesses using excel files as a database - it's a tool they already have and are trained on.

One of the reasons that we're still using a relational DB for our event storage is because of the transactional and durable guarantees that it provides.

I'm curious to get your take on how you would compensate for a lack of transactional/durable guarantees within a typical document database, such as CouchDB.  The biggest concern being that of a hardware failure before the document database has had the opportunity to replicate the committed transaction to the other nodes.

If we could skirt around the lack of these guarantees, we'd be able to completely ditch our relational database and use CouchDB, MongoDB, or some other variant.

Lastly, I realize that you're using a file-based implementation, but I've only ever been able to find little bits on how you do it:

tech.groups.yahoo.com/.../15415

tech.groups.yahoo.com/.../12396

When you use an inflammatory headline, don't complain about the comments. It just demonstrates naivety at best or cowardice at worst.

Your article had several good points, but if you are trying to engage or educate your audience, berating and belittling them

for their stupidity is not the right way to go about it.

I didn’t necessarily mean to piggyback off Greg’s two posts on ORMs but c’mon, what’s a hillbilly to

Maybe you should have called your post 'Using a <strong>RDBMS</strong> is like kissing your sister', to avoid confusion.

Using a database doesn't automatically assumes that you have to use a complex ORM too. Many people still do database programming without any ORM at all.

"few people did however actually understand the meaning of my post"... ooh.. so obscure. BS.

Another thing I'm thinking is support, especially if you are a Microsoft partner, Microsoft is actually very good at looking into problems for you if you have issues with a product of theirs (for example SQL Server). I'm wondering if you would get the same sort of mission critical responsiveness if you are using an open source ODBMS instead? I'm also thinking in terms of bugs, my gut feeling is you would find more in a relatively new ODBMS than a product used by a lot more people around the world and for longer amount of time and hence possibly more stabilised. I could be wrong however, that is just my hunch and not tested.

But, I would be keen to hear about your 3 most favourite object oriented databases for me to have a look into :)

Anytime someone says they need an RDBMS for their app because of reporting I cringe and feel sorry for their DBA. As you said, OLTP and OLAP are different needs and pulling reports from an app optimized schema on a production database is a great way to kill your scalability.

And that design decision doesn't have anything to do whether your app uses an RDBMS or not.

" I then ask them to put their hands down if there was any actual analysis done to come to that decision. Significantly less than 1% will keep their hands up."

I think you mean "keep their hands up if there was any actual analysis done", but this is actually an interesting way of making the point.

I still think an RDBMS is the right call more often than not, but regardless, it is a good point to make.

Hi Greg,

I think one of the main reasons of choosing the relational database is also the big companies that create these products. SQL SERVER by MS and Oracle cooperations.

They look at CouchDB and MongoDB as small pet projects with no support.

It will take time to get object databases into the main stream.

Your argument is the same as the OODB crowd has. In theory there's nothing wrong with the idea of thinking about the necessity of a tool and if there's a better one which fits the task better. That same thing can be applied to the OO nature of a language used to write the application against the DB. Sounds stupid? If so, why is it stupid to question the necessity of OO while it's not stupid to question the necessity of relational databases? :)

If you think about the theory behind entity models, and you have to if you want to use OODB's or code-first stuff as well, mind you, it's not really that big a question if relational databases are useful, they're not: you need a conversion layer between the two projections of the abstract model: the projection on code vs. the projection on the relational model. The O/R mapper makes it possible to get from one projection to the other and vice versa.

The point is that if you use the same projection on either side (so an OODB on the relational db side, or setbased code on the code side) you will give up on the advantages of the projection you replaced. Especially in the area of relational databases where the power is in the creation of new projections from the data.

IF you want to wonder if something is really necessary, IMHO CQRS is a good candidate. I can't help but think that CQRS is the most overrated overhead bull I've seen in a long time except if you are writing a very specific application, 99% of us are not doing that.

"Frans my guess would be you have that opinion because you don't understand what CQRS is."

Hey Greg - guess what? Frans is a pretty bright guy (except when he disses Nhibernate ;) ), and I would bet good money that he can read. Following that logic train, I would also bet good money he has read about CQRS enough to have an informed opinion about it. You just don't like that opinion.

I consider myself a very open minded developer, and have tried like hell to give CQRS a chance, at least in principle. And while Frans didn't sugar coat his comment, he does get to the heart of the problem with CQRS.

Back to the RDBMS topic though, you come across as very arrogant. From the original sensationalist "kissing you sister" headline to your pompous "you guys just don't get it" style remarks. If you are trying to educate developers about something, you are doing a piss poor job.

"Its also important to note that I never intended to speak out against the RDBMS but the storing of a relational model within one."

"One could as a commenter pointed out implement a non-relational model in a relational model. As an example I actually show people how to build an event storage system within a relational database quite often, it is not however a relational model."

So the author misspeaks but then accuses a commenter of constructing a strawman, then corrects himself in the next post.  Was it a strawman because I was supposed to understand the intent in your head, not the (poorly articulated) actual post?

But wait!  You also say:

"A few people did however actually understand the meaning of my post."

Greg, it sounds like you desperately want to blame failures to clearly articulate your thoughts on your readers.  Your readers can't be expected to read your mind and determine "intent" in spite of what you actually write.  You have the burden of communicating effectively.

It's extremely bad form for an author to make errors and then go around attacking people in comments and subsequent posts for misunderstanding.

"We need to actually be doing analysis of these requirements and leave behind the viewpoint of the RDBMS being the default. Examples of technical factors would be how well they match up with our functional specifications, examples in organizational factors might be what resources are currently available, whether we are fitting into a larger scheme of things, and of course cost."

I totally disagree.  RDBMS's have established reputations, work well, are easy to get started with and get real applications deployed on top of (e.g. a nascent version of a Rails app can be deployed within a day).  Your MySQLs and Postgres's are pretty simple to interact with and maintain.  It's a very small % of applications that will ever get close to the limits of what a single MySQL instance can do.  I can get DBA's and managed hosting organizations to competently back up major RDBMS's and provide SLA's.  As you point out, your typical RDBMS is pretty flexible in terms of what data models it can support.

Nobody should stop using their brains, obviously, but given all of the above I don't see why a RDBMS shouldn't be the default choice.  Or why all of this analysis is necessary.

"Its like people have ended up in that dreaded position where they have become comfortable with something so they just fall back on it for every problem, hammer anyone?"

I use files and unix acls and Apache and Cron.  You could say that cron is my hammer for kicking off processes on a schedule, but that's not an interesting criticism.  It works great, I know it's worked great for others and I'd like to move forward.

The NoSql tools are interesting and merit consideration.  But it's beyond obvious that (taking MySQL in particular) there are millions of production instances, and there's a huge array of businesses that are very happy with their choice, probably didn't think too much about it.  The vast majority of new users would be served well by choosing a RDBMS.  

They don't have to worry about what happens when Couch gets beyond storing a couple million objects, or Tokyo segfaults and becomes corrupt, the sparse support and in some cases meager communities surrounding some of these new tools.  The RDBMS setup and development experience "just works" in many typical webapp development and deployment scenarios.

It's actually more like kissing your mom.

Which I've done.

My point is that relationnal database are very good to store and doing request on data.

All is already done and is effiscient. You can do operation on millions of lines in no time and perform complex operation on then...

And this with just a few line of SQL code. Don't worry about memory management, don't worry about ACID. The database take care of all of this for you.

The same thing written in JAVA using an ORM will need, more more code, will be thousand time slower, may throw out of memory exception and things like that.

The code will be far far longer to write and maintain. People like ORM because they do not understand RDBMS and don't want to.

NoSQL datastore, keep most of the RDBMS properties if you care about performance and all.

But still for me it's a step downward you have lost constraint integrity, you have lost your SQL, that powerfull query language.

If you are a smart guy, you really know what NoSQL has to offert and what RDBMS offer. And in all case you know that for good performance, code that deal with the data shall be encapsulated as close as possible with the data... In stored procedure for exemple.

And so you know that in all case an ORM is only good for CRUD operations nothing more.

lol @antidotal evidence

ORMs are pretty good for fetching object graphs that you persist to a RDBMS. Doing that with plain SQL (e.g. JDBC in Java) is and always has been a pain.

You are so so so wrong.

There are a finite number of data models, relationships and needs.

All software writers should stop being complete assholes. My code should read:

Object.getAllExpiredRegistrations()

This should WORK without any more boiler plate code from me.

Am I wrong?

Why?

Well, I am not wrong, so screw you.

Oh, your captcha - it is a piece of shit. Nothing fancy about it at all. I can get a guaranteed 20% success rate out of it WITHOUT EVEN TRYING.

Of course, being slightly unique, you are saved by most of the bots that don't add the form values of 'first item in position x,y' to all their spam posts, which would be right 20% of the time. gaaaaaaaaay and stupid.

All captchas that reduce a success to a percentage, AND WOW, 20%! are USELESS. It just means you need to make 5x GET requests for each successful spam, hardly a problem AND PRETTY MUCH AWESOME.

Also, your fucking captcha discriminated against blind people, also I note that THE ICONS DON'T EVEN FUCKING CHANGE, so I can write a simple 100% effective work around and detection for this captcha in 2 minutes. Which is fucked since it probably took fucking hours to make this captcha. fuck me.

Not to mention mobility impaired people, also GENERAL USERS who don't recognize that as a captcha.

You think you are clever using that captcha? It is fucking stupid

People without mice? Keyboard bound people? People using speech synthesis?

YOU CANNOT BE ON MY INTERNETS BECAUSE I WANT TO USE SOME STUPID COPYPASTA CAPTCHA TO LOOK AWESOME AND GET DATES!

Stuuuuuuupid

"And so you know that in all case an ORM is only good for CRUD operations nothing more."

I don't agree with this. When you are working a really high performance system, then you may be in the situation where you really need stored procedures (but maybe you should think about your datamodel at those times?). However, I think most of the systems can work perfectly with an ORM, and perform very well. So stating that ORM's are only good when doing simple CRUD operations is very short-minded I think.

Linked -> List

Linked -> List

Greg, I imagine you know the saying that goes something like "the problem with lack of intelligence is that those who suffer from it don't posses the means to self-diagnose"?

It seems to me maybe you should think and listen more and write less.  I've ready likely all of the major papers / major blog posts on this topic, and believe me, yours is sorely lacking.

And I'm extremely curious, do you know who Frans Bouma is (or, did you at the point in time you replied to his comment)?   I can't imagine you actually knowing who he is, and then proceeding to say:  "my guess would be you have that opinion because you don't understand what CQRS is"

Frans Bouma is actually a pretty well known guy, at least in the .NET and ORM scene.

NoSQL: Getting started with MongoDB and NoRM

Reading this post is like kissing a dead bird carcass.

No, but seriously, good post. The point is "is there ever a thought about this?".  And he's right, in certain circumstances, there probably should be. It mostly likely fits really well for his particular circumstance, and is why he feels so strongly about it.

Regarding CQRS, I have found these concepts very useful when thought of at a birds-eye view. The domain is only concerned with changes. It's as simple as that. Querying does not need to go through the domain, and you wouldn't want to return domain objects from a query anyways. You want to return something that has the specific purpose of being bound to the screen (a screen DTO). The DTO should have the "id" representing that entity, so that it can be passed back when passing changes to the domain.

I think this comes down to the fact that DDD is something that most people really don't understand. They think that using an ORM is using DDD, and that's far from the truth.

The domain layer is all about managing core aspects of the problems you are solving, and this has nothing to do with querying. Simple, and clear. Probably the most important pattern that has come out in the past few years.