Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Don't use foreign keys – dukeofgaming Jul 31 '12 at 2:24
Don't use SQL :-). Seriously, does "NoSQL" tell you anything else about the technology? – user4051 Jul 31 '12 at 10:36
I think this thread should be in the Database site of Stack Exchange. There you could find more help about this issue. – Luis Arriojas Apr 18 '14 at 15:54
up vote 10 down vote accepted

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:

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.