2.0 Schema Design

2.0 Schema Design

Schema Design depends on the design of the application using it.

Schema design comes in two versions: Embedded and Referencing.

In Embedded design the collection stores multiple documents nested within other documents. If data from several SQL tables is usually accessed together, it can be nested in one collection, which will improve speed.

In Referencing design the collection stores reference ids of documents from other collections.If needed, the reference ids are used to access corresponding documents from other collections.

Schemas can also be designed in tree format.

The below Process shows how to collapse 2 RDBMS Tables to 1 BSON Documents.

Step1: Drawing Diagram

What are the rules to model a document db?

• natural and intuitive structures
• 1:1 or 1:many relationship is candidates for embedding (HAS-A relationship, Composition relationship)
• many-to-many relationship is candidates for referencing

More consider:

Even if there is 1:1 or 1:many relationship, if:

• A parent document is frequently read, but an embedded document is rarely accessed,
• One part of a document is frequently updated and constantly growing in size, while the remainder of the document is relatively static,

then, consider using referencing, and if:

• The document size exceeds MongoDB’s current 16MB document limit
• Referenced from many different sources
• To model large, for example, hierarchical data sets

then, consider using referencing.

[RDBMS Modeling]

[Document DB Modeling]

Step2: Filling out schema mapping chart that we will use to map some of the tables we are transferring

Step3: create a schema in which we embed an array of sub-documents within primary document

import_product_M collection: 

{
	pid: 1,
	gtin: “000123456789”,
	...
	,
	import_product_version_M: 
	[
		{ 
                        pid: 1,
                        gtin: “000123456789”,
			version_id: 1,
			version: 1973,
			productName_en: "Lenobo T570",
			productName_fr: "Lenobo T570",
			...
			,
			import_product_version_allergen_info:
			[
				allergen_name_value: "Apple allergen",
				allergen_name_value: "Banana allergen", ...

			]
		},
		{ 
			version_id: 2,
			version: 1979,
			productName_en: "SAMSUNG Monitor ABC001",
			productName_fr: "SAMSUNG Monitor ABC001",
			...
			,
			import_product_version_allergen_info:
			[
				allergen_name_value: "Apple allergen",
				allergen_name_value: "Banana allergen", ...			
			]
		},
		...
	]
}

What are the advantages of BSON Document model?

• Provides more natural and intuitive way to represent data

• Performance and Scalability

  • less cares about relationships among entities. Using relationship keys spend more resources costly
  • distributing the database across multiple nodes (a process called sharding), to achieve massive horizontal scalability on commodity hardware
  • no longer needs to worry about the performance penalty of executing cross-node JOINs (should they even be possible in the existing RDBMS) to collect data from different tables.

• can be accessed with a single call to the database

• The MongoDB document is physically stored as a single object, requiring only a single read from memory or disk (On the other hand, RDBMS JOINs require multiple reads from multiple physical locations)

See More: RDBMS to MongoDB Migration Guide