Would these two scenarios be good candidates for a NoSQL database?

Question

I've checked a few other threads around the topic and search around, I am wondering if someone can give me a clear direction as to why should I consider NoSQL and which one (since there are quite a few of them each with different purposes)

• Why NoSQL over SQL?
• Is MongoDB the right choice in my case?
• https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-goin

Like many others - I started with relational databases and been working on them ever since, thus when presented with a problem, the first instinct is to always think of "I can create these tables, with these columns, with this foreign keys", etc

My overall goal is How to get into "NoSQL" mindset? ie getting away from the inclination of always thinking about tables/columns/FKs (I understand that there are cases where RDBMS is still the better way to go)

I am thinking of 2 scenarios for example just to get more concrete direction

Scenario 1

Imagine a database to model building a furniture instructions (think of IKEA instructions) where you would have the object "furniture" which would have a list of "materials" and have a list of "instructions"

• Furniture - would simply have a name that have a list of Materials and Instructions
• Materials - would be a name + quantity, may be we can even have "Material Category" table as well
• Instructions - would simply be an ordered list of texts

My first instinct would go the RDBMS way:

• Create a table called "Furniture", "Material" and "Instruction" and the approppriate columns
• Create the appropriate JOIN tables as necessary and FKs

The use of this system can include searching based on materials or may be combination of materials. And may be think of extending the data stored to include information on how many people are required to build it? Difficulty level? how much time it would take?

Would something like this be a good candidate for a NoSQL database?

Scenario 2

Imagine a database to model a User database with basic information (eg. name, email, phone number, etc), but you also want to have the flexibility of being able to add any custom fields as you wish.

Think of different systems consuming this user database, each system will want to have their own custom attribute to be attached to the user

My inclination would go the RDBMS way:

• Create a table for "USER" with columns: ID, name, email, phone
• Create a table for "USER_ATTRIBUTE" with columns: ID, USER_ID, attr_name, attr_type, attr_value

The USER_ATTRIBUTE will allow that customization and flexibility without having to shut down the system, alter the database and restart it.

Would something like this be a good candidate for a NoSQL database?

Answer 1

NoSQL isn't a very well defined term and all the solutions that run under this name have very different features, so a lot may be possible or not depending on what exactly you are planning to do with it.

Basically you could use some of the more general solutions like maybe MongoDB or Cassandra to simply replace your current relational database. In some cases this makes more sense in others less, but it will work once your team got used to it. Certain things will be easier then, others will be more difficult and you must weight those options against each other and decide (which often enough will mean that there are no advantages big enough and the simple fact that everybody in the team feels most comfortable with relationals and SQL will make the decision easy)

Other NoSQL solutions that are more specialised are not really good candidates to replace your relational DB, like graph databases or simple key value stores. So lets from here talk mainly about those databases that are at least to some degree similar to relational databases.

Scenario 1

Where I work we have exactly this scenario, though quite more complex with a lot of different attributes per article. Some of those attributes in hierarchies like Apple -> iPad -> Air.

The data is still stored in a relational database. But: searching this in real time became a pain. With SQL it was slow and code would have been terribly complex. Selects over many tables, with the additional option to exclude certain attributes like "not blue".

In this case Apache Solr or Elastic Search are a solution. Though of course data is duplicated from the relational database.

But from here our experience with this kind of document store showed that it can handle certain problems very well and we will consider to replace part of the existing relational structure with some other kind of storage. So not the whole database where we also store all the transactional data like orders etc, but for example take out all the attribute information which can be handled much better in the aggregate like data structures of NoSQL.

Scenario 2

Difficult to say, since what you describe is most likely only a very small part of your user handling. Having schemaless storage is an advantage with many NoSQL databases. But some relational databases allow to store such data too (as long as you don't need to query it via SQL in most cases).

Cassandra for example would allow you to define column families in such a case, where your first set of attributes would be one such family and the variable attributes another one.

As somebody said: NoSQL is less about storage and more about querying. So the question is what will be the typical use case for those queries.

A typical problem would be the transactional data here. If you want to store orders, one way would be a schema where users and their orders form an aggregate (kind of user document that contains the orders as subdocuments). This would make getting a user together with his orders very simple and fast, but would make it very difficult to retrieve all orders from last month for sales statistics.

Also strengths of NoSQL solutions are that it can be easier to run them on multiple clusters if you have to work with very large datasets.

Conclusion: Both your scenarios could be modelled with certain NoSQL solutions, but I don't think that (assuming they have to run in a larger environment) they really justify a large extra effort in learning, training and implementation and maybe some other additional disadvantages because both are not specific enough to really leverage the strengths of NoSQL. At least not in that simple form you describe it. Things may become very different once some aspects you describe would be very, very prominent in your usage scenario, like in scenario one the attribute data becomes very complex or in scenario two the variable fields become the largest part of data you store with every user.

Answer 2

I've been using document dbs (ravendb to be specific) as my data store of choice for 3+ years now and I really don't want to look back.

At least for that sort of nosql databases the biggest question is "what goes in this document? What goes in another document? What goes in a related document?" Unfortunately there isn't a lot of good guidance on this. Then again RDBs are a 30+ year old technology so there is a pretty massive body of work there but there still are not perfect answers to all problems -- for example I would reject any entity-attribute-value solution like your scenario #2 without real, real good reasons to go EAV -- I would rather model data extensions as sub-type-tables or using some sort of extensions field comprising serialized data.

Anyhow, there are no perfect principles but there are some good guiding principles one can follow. The two that have helped me the most are:

1. Model your documents around transaction boundaries. Joins are much more expensive to work out and use with objects so being able to select a Foo by ID and getting all of foo makes a ton of sense and makes things easier to work with on many levels. Now, this is not to say everything need be some massive document -- transaction boundaries can be more confined than "everything to do with a piece of furniture". In the case of your scenario #1 I would probably look at the transaction boundaries as the Furniture including Materials and then a separate Instructions document. The logic being you probably manage furniture and materials together but the instructions likely come from somewhere else. Keep in mind that aggregation on the front end is pretty cheap. Categories is an interesting example which leads me to . . .

2. Data duplication is a-ok if you manage it right. A major underlying principle of RDBMS is "don't duplicate data" largely because it grew up in a world where disk storage was orders of magnitude more dear than it is in 2014. For document-style databases it can make sense to have copies of things within your transaction boundaries. For example let's take the furniture categories from scenario #1 -- I would probably have a FurnitureCategoryDocument that would have all the information about the category. I would also have some key information -- ID and name at least -- embedded in the documents for ease of use. This is just fine so long as you can cascade updates, which requires more code than ON UPDATE CASCADE, in your app.

Hope this helps demystify things a bit.