NoSQL and SQL

So... I've written about this before, but I loooooooooooove SQL, in particular I loooooooooooove Microsoft SQL Server. The whole relational database thing really works for me. Its elegant and if done right should make sure you're data only ever appears once etc, however I think I like NoSQL too now... how fickle am I?

The first time I heard of the whole NoSQL thing I sneered and thought, 'why would you want to? SQL is the way to go'. Then I came across Azure Table Storage and now I'm hooked. Okay, the whole Partition Key/Row Key thing can still give me nightmares of the 'what's the best key strategy?' dilema, but, I'm loving the speed and completeness of the data storage.

I know that as a Developer you design your business objects against the Function not the data store, I.e. a Member relationship table pointing to a Person and Address becomes a Member business object which encapsulates the Person and Address fields thus giving context to the Person and Address details, but it took a while for me to work that one out. I thought the whole point was to have a business object called Person, another called Address and a third called Member, just like in the database not realising that this is the best way to create orphaned records, but I think I've gotten over that now. The thing is though, that that Member business object, looks like it's just been made for NoSQL storage. I mean, surely all I have to do is create it and then hoof it straight in to the database and I'm done. Okay, so the SQL server side of me is now having kittens thinking about data duplication and data separation, but, hey at least I've got my data stashed now, haven't I?

I've been a full stack developer now for years and am as comfortable working with the front end code as I am comfortable dealing with the back end database, specifically SQL Server, so I've always thought that I have a pretty good view of the whole caboodle. Since I've been used Rockford Lhotka's Csla.net framework and it's concept of 'Smart Business Objects', a business object that knows at any time if it's valid and who's allowed to see it, I've deferred a lot of the management logic from the SQL side to the Business object side using the 'dumb' database method. Sure I build in various checks on the SQL server, but by the time my data hits the server, I can be certain that it really should be there in the state it's in. Utilising a 'Smart' business object, I can make my object aware of any related objects that need to be amended, deleted or whatever just before writing back or immediately after. Which all goes someway to alleviate any panics that I had regarding potential duplication of data in a NoSQL database, but, it's been occurring to me more and more that an ideal scenario would be a combination of 'Smart' business objects, SQL Server and NoSQL.

The way I see it is this, you use SQL Server for your hardcore, rock solid, no duplication data storage. This is your one source of truth. You can optimise it to be uber flexible, give it a small footprint and, as a big fan of 'normalization', normalize the hell out of it. You can then utilise the NoSQL to create what in effect would be a series of SQL Views, except these views require no joins as they're already compiled and ready to go, in effect. The flow of the data would go, 'Smart' Business object, to SQL Server to NoSQL. No data would be written primarily to NoSQL as NoSQL isn't there to manage the data, only to provide readily available snapshots. A Microservice could be put in place to manage the transfers between the SQL and the NoSQL utilising exactly the same 'Smart' business objects and potentially injecting them straight into the NoSQL. Saying that though, I'm using Azure Table Storage for data storage for all of my Azure Web Applications at the moment because it is waaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaay cheaper.