Actually there is a lot of value in using NoSQL in ecommerce sites.

One of the biggest headaches facing DBAs today is IO. Processing power is cheap, memory is cheap, disk space is cheap but until large, cheap, reliable SSD or better technology becomes available IO is the bottleneck.

NoSQL offers a potential solution so as DBAs we should be embracing the possibilities it offers while scrutinising its use in our role as data professionals.

Lets consider the eCommerce site. We are adding things to a shopping basket, as are many tens of thousands of people, but until we commit to pay for it the world won't stop if there is a hiccup in the shopping basket service. Provided at the point of commit we have full resilience and robustness a NoSQL solution could save a lot of IO.

The reality is that hardware is very reliable and very high uptime achievable so the glitches that a proper RDBMS will handle via 2 phase commit are few and far between. Obviously I wouldn't trust sensitive financial transactions to any existing NoSQL solution but as a tool to act as a transient store NoSQL offers a lot of advantages.

I almost feel that SQL Server should have a NoSQL provision in its storage engine. Being able to define a database in zero recovery mode so the overhead of the 2phase commit is eliminated. SQL Server already uses file based error logging for the SQL Server Agent and MSSQLSERVER service.

Imagine a reindex process where the overhead of TempDB was halved! Obviously the reindex process would have to be sensitive to glitches even if all the reindex process did was abort in the event of a problem.