best practices for NoSQL database design

Question

I have just started using a NoSQL document based database (MongoDB) and i'm curious about the best practices for designing databases.

I presume the architecture should be different from relational databases? Should I still aim for a normalized database?

For example I have a particular use case;

I have a user with a rental history (array of addresses) should that array be an array on the user or as a separate collection with a shared key?

Answer 1

Appropriate approach for NoSQL database design is a DDD (Domain Driven Design ). For some people who used to design RDBMS, NoSql looks like Sql anti-patterns and it make more sense when considered in a scope of a DDD.

Depending on usage of addresses, you may define it as a value object inside your rental history model/entity.

Here you are some references that might clear the thoughts on design with NoSQL:

• A Managers Guide to NoSQL
• Wakanda: NoSQL for Model-Driven Web applications - NoSQL matters 2012
• Addressing the NoSQL Criticism
• Our experience with Domain Events

Answer 2

I have a user with a rental history (array of addresses) should that array be an array on the user or as a separate collection with a shared key?

Please note that this answer is not about MongoDB in particular.

This is logical database design question and is not much related to whether you use NoSQL or SQL.

The normalization rules are independent of database implementation. If you have repeating groups (rental history in this example) you are violating normalization rules.

Having said that, you either stop here or continue examining how bad it is if you violate the rules.

The question becomes what functions will your application perform on the rental history? And how many Rental History occurrences are there. The number would affect the row length and there may be limitations on that or performance degradation if you have a huge row length and you plan to access large number of rows. So this one concern. Back to functions performed on rental history, you may have functions like:

• Add rental history given user key (if you only append it to the end of the list, no worries).

• Update rental history given user kye (if you update it in place, then no worries)

• Delete a rental history given user kye (this sounds illogical but it is also not too bad)

• Search for rental history value given user key (this should be OK)

The above is true assuming that the renal history is a simple structure that can be parsed without complications and that you will not use the rental history in a Many-to-Many relationship either now or in the future.

However, the function:

• Search for a rental history (without a given user key) is bad if you expect to perform it often because it may cause a full table scan (which is bad if you have large rows and large number of rows).

Also, with having several rental histories in one row, uniqueness of any given one will not be determined by the database since there is no PK and hence this is something your code needs to take care of.

Yet another thing that you will have to code for yourself is aggregation if it applies to your case (Count, Group By, etc.) - All those functions are not there. Same is for sorting.

So the choice is yours.