And you are here why?

(aka: “ Phonebooks vs Book Indexes ”)  A clustered index is best thought of as a phonebook (°) — you index by a column, and all the data for that row is right there, next to that key. A non-clustered index, OTOH, is like the index in the back of a book — topics listed by alphabetical order, and pointers to every page where that topic is covered.  The key difference being that in non-clustered indexes, getting at the data is a two-step process (find the topic, then find the page) And yeah, it’s not quite this straightforward, but it should get you started… (°) “ Note to future SQL developers in 2030 who have no idea what a phonebook is: it’s something that stores the names, addresses, and landline phone numbers in your area. What’s a landline? Oh boy…” —  https://goo.gl/VXCPG3

Back in 2009, C.L. Moffatt put together this gorgeous cheat-sheet on SQL JOINs As he put it I'm a pretty visual person. Things seem to make more sense as a picture. I looked all over the Internet for a good graphical representation of SQL  JOIN s, but I couldn't find any to my liking. Some had good diagrams but lacked completeness (they didn't have all the possible JOINs), and some were just plain terrible. So, I decided to create my own and write an article about it. Enjoy... Hat tip Alex Popescu

Matthew Aslett has an updated version of the database landscape chart that he had put together a while back - done in hardcore London Underground style (and it is the better for it). Check it out (click to embiggen...)

New Trade Theory is a pretty good explanation of how MySQL / PostgreSQL / Oracle / SQL*Server can all co-exist Seriously - they're all pretty identical (for the vast majority of use-cases), but if you factor in increasing returns to scale , and network effects , it all makes sense...

There seems to be a pretty potent Meme floating around right now viz. The Future Of NoSQL - To Be Borged .  The general argument seems to be some combination of  Databases are complex beasts We've spent eons simplifying access to these data stores (SQL) BigData revolves around an even more complex set of problems Everybody is building custom solutions to these problems Regression to the mean will result in them all becoming somewhat similar SQL stores will just add these common features All your bases will belong to them  As you might imagine, I quite disagree with this. Oh yes, I fully expect SQL DBs to incorporate some NoSQL features over time, but it really isn't the same as when Object Oriented Databases went to the Great Dustbin In The Sky.  As I've mentioned before, NoSQL stores are more solution-oriented - there is a huge and thriving ecosystem, and the vast majority of them are designed around specific types of solutions.  Can they be ...

You had to be hiding under a rock to not have seen the (anonymous)  Don't Use MongoDB  post that has been making the rounds.  I've replicated it below, just in case it vanishes. The author is (as of  this writing) unknown, but he/she brings up a lot of points.  For what its worth, I completely agree with the final recommendations, viz. 1. Don't lose data, be very deterministic with data 2. Employ practices to stay available 3. Multi-node scalability 4. Minimize latency at 99% and 95% 5. Raw req/s per resource Obligatory caveat here - I'm a big fan of BigCouch , and have been using it for a while now. That said, to defend Mongo (just a little bit. and yes, it hurts), when we started going down the CouchDB  path, I knew  what I was doing.  I'd read everything, I'd tested the bejeebers out of Couch (especially in the 0.9.0 days), and already had a pretty thorough grounding in NoSQL tech for a variety of unrelated reasons which I won...