4

What kind of NoSql data modelling is best suitable for the following requirement?

This can be visualised (NoSQL-Document) as a Collection of Records where each Record contains nested Documents.The nested document entities at different levels are either flat or tree structure based. A Record is structurally a single entity, i.e., a deletion of a record deletes all of the record and its module data.

enter image description here

The nested documents type model does not provide the flexibility in querying the sub-document items but keeps the structure of the record straightforward. On the other hand, if the Modules are represented as different Collections then it may improve querying but the reference and join operations have to be handled back end.

The typical use cases of the system are, the model entities can grow up to 100,000 items per module, more-frequent query and less-frequent update of the entities and heavy cross reference of entities (for example, an entity deep inside the tree structure in module B referring to an entity in module A).

If the Modules are implemented as separate documents then maintaining the relationship between the corresponding record and the module entities would become cumbersome. This will become a more serious problem if the number of records increases then the respective module collection will grow significantly more without bounds, whereas embedding the module inside the record will grow only up to 100,000 items.

One proposal for the above issue. Create separate documents with Record+Module information then this can be treated logically grouped as a single entity. For example, Record1 as one document, ModuleA of the Record1 as Record1_ModuleA document and so on. This way the documents with the record id+module name combination can be grouped to form one entity.

Does any NoSQL Db support grouping of related documents? In this case, the record document can be grouped with its modules as separate documents and the group can be logically identified as a single entity of record.

Right now, I'm thinking in terms of Document Databases. Could this be efficiently handled with any other data modeling techniques?

KDR
  • 153
  • 8
  • a some-sql data model – Ewan Feb 20 '18 at 13:41
  • Or both. One for querying over metadata and other for retrieving – Laiv Feb 20 '18 at 14:27
  • @Laiv, your comment makes sense. I've updated the question with more details. – KDR Feb 20 '18 at 17:05
  • "NoSQL" and "Document database" are general characteristics, not a common feature set. If you are looking for efficiency of storage, maintenance, and traversal of your data model (rather than lowest common denominator), I would choose a specific data store to make your question more answerable. Another factor would be your common queries and updates. You mention up to 100,000 items per module but are you typically going to be querying a subset of recent items or fetching the full set? How many levels of nesting do you need? – Stennie Feb 20 '18 at 21:41
  • @Stennie, The query for the items will frequently be a subset in the range of 100-500 items. The Module nesting is always one level but the items inside the module in tree structure is not controllable but with the maximum limit of 100,000 items. Does any NoSQL Db support grouping of related documents? I've updated this in the question. – KDR Feb 21 '18 at 08:06
  • 100-500 is no longer `collection will grow significantly more without bounds` – Laiv Feb 21 '18 at 19:52
  • @Laiv, It is only the "typical-frequent" queries that are in the range of 100-500 the maximum item that a module document can contain is still 100,000. The statement what I meant is, if Module is normalised as separate document then as Record grows then Module items grows in the multiple of 100,000 and there is no restriction on the number of Records. I've mentioned one proposal for grouping of the Records and Modules but not sure whether it is a proper approach. I've updated the question again. This is a kind of learning for me. – KDR Feb 22 '18 at 03:41

0 Answers0