Posts
1150
Comments
891
Trackbacks
1
Please don’t save your view models in your database

For various reasons, I was watching this to learn more about the latest version of Raven DB 3.o (basically, I have a big event/command store and I want to process the raw data into multiple different ‘buckets’ and am looking into various options, including SQL and NoSQL options).

Before I get to my main point….

Normally, I wouldn’t pay much attention to mistakes/issues with the presentation itself.  Things happen.  Network connections go out, that sort of thing.

However, if you are trying to give an example that is key to your overall presentation, and it is not the best example in the first place, then you really need to make sure it works.

For instance, one of the ‘big deals’ about NoSQL, at least in some corners, is ease of developer use.  You can just ‘get coding’ and not have to worry about things like creating databases and tables and schemas and all those horrible things that create ‘friction’ and whatnot.  This is, generally speaking, wrong on multiple levels, but okay, let’s go with it for a minute.

If you are going to use as an example how easy it is to add a property to your object model, and having it add default values to existing objects, as a supposed example of how ‘frictionless’ this is (since adding a column to a table with a default value is so freakin’ hard, you know), then you should actually be able to show that in your presentation.  If you can’t get something that basic to work then it really kind of undercuts the whole, ‘it just works’ vibe you are trying to share.

But besides that….

It is given as an example that when designing the UI for a home page, you might have to do a whole bunch of nasty joins to pull back a bunch of information and isn’t it so much easier and better to be able to just save your view model objects in your database instead.

No, no, no, dear Lord, sweet Almighty, no.

The whole ‘Vietnam of Computer Science’, object-relational impedence mismatch thing is largely a load of hooey.  It isn’t difficult to do these sorts of things.  It is absolutely the case that sometimes, dealing with databases and joins and schema changes and (God help us) database administrators can, and this is a technical phrase, suck.  There is no doubt about this.  But, for the most part, if you are having problems with those sorts of things, you are doing it wrong.

The last thing you want is enabling your developers to randomly persist objects in a database, NoSQL or not, without thought, and think you are going to be able to build a reliable, sustainable system.  You really can’t fix these sorts of things with some magical combination of Hadoop and map-reduce.  Crappy NoSQL persistence is still crappy persistence.

So, please, don’t do that sort of thing.

Thank you.

posted on Friday, December 12, 2014 11:20 PM Print
Comments
Gravatar
# re: Please don’t save your view models in your database
xiety
12/15/2014 1:53 AM
How is this corresponding to Udi Dahan's Clarified CQRS:

"Then our client could simply SELECT * FROM MyViewTable, and bind the result to the screen."

http://www.udidahan.com/2009/12/09/clarified-cqrs/
Gravatar
# re: Please don’t save your view models in your database
jdn
12/15/2014 12:01 PM
@xiety:

I do not particularly like that approach. Unless you need it, of course (which would involve cases where you simply do need materialized views, as opposed to, well, just views).

However, that is still quite different. You have an event store that is driving eventually consistent view model 'respositories', it is still (generally/usually/caveat placed here) an extension of a relational model.

Post Comment

Title *
Name *
Email
Url
Comment *  
Please add 2 and 8 and type the answer here: