SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

A Tool for the Job

By Phil Factor,

There is just a short distance between 'I can’t see how to do this with a relational database' and 'this shouldn't be done with a relational database'.

The great strength of relational databases is that they can be adapted for a wide range of tasks. They do some things slowly or ungracefully, but a properly-designed SQL Server database can generally get the whole job done. Without blushing, I can say that I've never faced a database problem so obscure that I couldn't do it in SQL Server. Would the application have been quicker had I grabbed one or more specialised NoSQL databases, and would the performance gain would have been worth the on-cost in training and support? There is value in having a consistent architecture

So what shouldn't be done in SQL Server? Andrew C. Oliver, ('I am a NoSQLer and a big data guy') lists ten things never to do with a Relational Database in an interesting article on InfoWorld. It is a useful list to help us understand why NoSQL is sometimes chosen:

Search ('Outside of Oracle, many other RDBMS products don't have real search extensions').

Recommendations e.g. People who bought torches often bought batteries too ('that gets ugly in the RDBMS').

High-frequency trading ('High-frequency traders were among the first people to adopt and, in some cases, create NoSQL approaches. Low latency is king for HFT').

Product cataloguing ('Had we kept the product information in a graph database, it would have been simple to map').

Users/groups and ACLs: ('To some degree, LDAP was the original NoSQL database').

Log analysis: ('they really don't need transactions, and low latency is job No. 1').

Media repository: ('You're better off using some kind of distributed storage or clustered file system for your images and other binaries').

Email: ('Email really is moderately unstructured data with metadata that is best stored another way').

Classified ads: ('There's search, there's metadata, there's short-sweet content. Eventual consistency would be good enough here').

Time-series/forecasting: ('The issues surrounding time in relational databases are the stuff of legend').

I find this list fascinating, and useful to get some clarity from a NoSQL/Big-Data fan about those commercial problems for which he considers an RDBMS unsuited. I have my own views about this list, but I'd be more interested in yours, since I suspect that those people who come up with SQL Server algorithms for these problems don't necessarily share their techniques with others unprompted. Consider yourself prompted.

Total article views: 192 | Views in the last 30 days: 1
Related Articles


Introduction Despite the traditional relational DB world, there’s also a trend for NoSQL. The NoS...


NoSQL Complaints

One NoSQL database is not necessarily like another. Steve Jones notes that some of the complaints ou...


NoSQL is Not the Answer

NoSQL solves some problems in the database world, but not all of them. It's also not an evolution of...


NoSQL: Are you ready to compromise with security

Before adopting NoSQL for a commercial application that needs consistency and durability, you need ...


Types of NoSQL databases

A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means oth...