4

When it comes to laying out tables in transact SQL databases, like SQL-Server and Sybase, the classic approach to relational modelling is well established. (The authority being Halpin's book)

  1. Establish your use cases
  2. Establish your entities
  3. Determine the attributes of the entities
  4. Determine the relationship between the entities
  5. Layout the tables with the joins to satisfy the use cases in the query
  6. Refactor the tables to nth normal form as required.

(or some variation thereon).

For Cassandra databases - this pattern is slightly modified, in that you have to start with your use cases, and then design for zero joins at query time. (The authority for this approach is the datastax training documentation).

You could say that you leave your tables fully denormalised at the level of the query for your use-case. So the pattern is more similar to:

  1. Establish your use cases
  2. Establish your entities
  3. Determine the attributes of the entities
  4. Determine the relationship between the entities
  5. Layout the tables denormalised to satisfy the use cases in the query

Now MongoDb is a document based database with the ability to do joins.

My question is: What is the canonical pattern for database design with MongoDB?

Improve this question
4
  • 4
    There's plenty of information about this on the Internet already, if you care to look. For example, this: tutorialspoint.com/mongodb/mongodb_data_modeling.htm
    – Robert Harvey
    May 12, 2017 at 14:16
  • 1
    I voted to close your question because it is too broad. Teaching database design from scratch is not something we do here. Ask a more specific question like "How are joins handled in MongoDB?"
    – Robert Harvey
    May 12, 2017 at 14:31
  • Thanks @RobertHarvey for the link. Perhaps you can explain why this approach is different to the two patterns above. (I respectfully contend that this question is not too broad for a site about software engineering).
    – hawkeye
    May 13, 2017 at 4:56
  • 1
    There's no "connect the dots" to be done here... you have to design a database. Stop looking for patterns to follow and break out your design skills.
    – Robert Harvey
    May 13, 2017 at 13:42

1 Answer 1

Reset to default
0

Based on the helpful information provided by @RobertHarvey - we can see that the MongoDB design process is similar to Cassandra's design process. (Whilst it has joins - you shouldn't use them for reading data in a query).

So the process will look like this:

  1. Establish your use cases
  2. Establish your entities
  3. Determine the attributes of the entities
  4. Determine the relationship between the entities
  5. Layout the tables with the joins to satisfy the use cases in the query
  6. Refactor the tables to nth normal form as required.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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