Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
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: 190 | Views in the last 30 days: 1
Related Articles

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...


How to understand NoSQL Databases

Today we have a guest editorial from Phil Factor that looks at NoSQL databases.


Relational databases vs Non-relational databases

I see a lot of confusion about the place and purpose of the many new database solutions (“NoSQL data...


Join the most active online SQL Server Community

SQL knowledge, delivered daily, free:

Email address:  

You make SSC a better place

As a member of SQLServerCentral, you get free access to loads of fresh content: thousands of articles and SQL scripts, a library of free eBooks, a weekly database news roundup, a great Q & A platform… And it’s our huge, buzzing community of SQL Server Professionals that makes it such a success.

Join us!

Steve Jones

Already a member? Jump in:

Email address:   Password:   Remember me: Forgotten your password?
Steve Jones