Rules of Engagement: NoSQL is SQL Server’s Ally is the title of a presentation that Dave Valentine (Blog | @IngeniousSQL) and I plan to give several times this year. Your knee jerk reaction to this title was likely negative, if you are like many other SQL Server professionals. And I can’t blame you, because I was once in the same boat. However, we have positive, real world experience working on an enterprise project that benefits from Polyglot Persistence. It isn’t all unicorns and rainbows, but it definitely has its merits.
Unlike other presentations or articles, our goal isn’t to explain why SQL Server is superior, or why NoSQL is more scalable (as a matter of fact, we will table those debates). We decided to create a presentation that explains NoSQL from our own perspective. Our goal is to educate our audience about why the various flavors/genres/categories of NoSQL came to be; and how understanding their strengths and weaknesses can enable you to offload work that isn’t a natural fit for SQL Server to another data store.
This will not be a history lesson, and it most definitely will not be a SQL Server bashing session. That said, while SQL Server is a great all-purpose database, these NoSQL databases were built to solve specific problems that relational databases don’t do well. We don’t plan on diving into NoSQL code, because that is primarily developer domain. But we will be discussing some real world examples at a level deep enough where a SQL Server DBA can see where a NoSQL solution might be a better way to solve the problem. There are no silver bullets, there’s always a trade off. So, we will talk about ACID, BASE, and CAP Theory. However, it’s not SQL Server or NoSQL. Polyglot Persistence is always an option, and we will discuss the good, the bad, and the ugly.