The people who would sing the praises of NoSQL will tell you that it is snappier than SQL, more performant. Certainly the joins in T-SQL are where the expense tends to lie in a given query, and solutions like SOLR (Searching On Lucene w/Replication, the replication part being a slave/master distributed server setup) are sidestepping the relational part of a relational database and offering you up one big flat table in the name of snappy search and I suppose there is a place for that in the NoSQL place too as suggested here, but when would I ever want an application to be end-to-end in NoSQL as opposed to just using NoSQL around the edges a little bit? When wouldn't I want relational data whatsoever? The interviewing process at @hand had one show off an application they authored. One of the guys they interviewed while I was there had an app in NoSQL and afterwards Bryan Harclerode criticized the guy for grabbing a bunch of objects in one "query" and then getting the keys for another object off of those objects and looking up the relating objects with the keys. When I asked him what that kid should have done with MongoDB instead the response was that you shouldn't use Mongo if you need relational data! When would I not be in this situation when baking out an application however? Even if I started out not needing it, what if I need it eventually? In a rolodex app in which people have addresses and it is possible for two people two have the same address would address just hang off of each person with dupes existing and would I always look for addresses through people as the front door? Always? Really? I've never been on a NoSQL project. In my job adventurers it just hasn't come up, not in a decade of NoSQL existence. People expect T-SQL of me. I can see why.
No comments:
Post a Comment