0

Hello we are currently building a mini company management & social site in node.js. First of all I'd like to mention that I'm new to mongodb, secondly I'd like to briefly state some database architecture entities so you may advise me or propose the right architecture I should implement on a mongodb database.

The website features:

  1. companies
  2. user groups
  3. user roles
  4. posts on user profiles
  5. posts on user groups
  6. posts on projects
  7. comments for posts
  8. calendar events for users, groups, companies
  9. clients
  10. suppliers
  11. project tasks
  12. project statuses
  13. task statuses
  14. task priorities
  15. tags
  16. real time chat & instant messaging & archiving

These are some of the website features. Currently we implemented this with mysql and a orm2 (Object Relational Mapping), however we came to a point were we think that mongodb would be more handy. Also most of the above entities were merged in a single table making it huge and lead me to believe that this is a bad practice.(imagine a table storing instant messages of 100++ users & posts & comments & events & tasks...)

Currently I'm thinking of mongodb database with 4-6 collections keeping the core entities separate and for example merging entities like comments inside the corresponding post in a posts collection.

Question: Is it a bad practice (in a MySQL database innodb for our case) to merge entities under a single table making it huge over time and does this apply in mongodb as well and at what extent? I've also read articles were they used a relational database for users roles and groups and a nosql database to store large amount of data.

PS: I'd appreciate any db collection / architecture proposals.

Community
  • 1
  • 1
0x_Anakin
  • 3,229
  • 5
  • 47
  • 86

1 Answers1

0

Merging entities is known as denormalization and has pros and cons. It is usually recommended to denormalize only to address an actual performance issue.

Use a relational database to store relational data. Use a flat structure to store flat data. Full stop. Don't use a truck to run a race, even though a truck has more horse power than a race car.

Community
  • 1
  • 1
RandomSeed
  • 29,301
  • 6
  • 52
  • 87
  • Architectural recommendations would be off-topic. – RandomSeed Aug 22 '14 at 12:13
  • Relational database systems are actually very bad a storing relational data - if your entities are heavily linked to each other, consider switching to a graph database. Unlike RDBMS, there's no need for a join for every relationship and it's much more efficient to traverse. [ArangoDB](http://arangodb.org/) offers a combination of document-store and graph-store, which can be very handy. – CodeManX Jan 16 '15 at 13:12