MongoDB Collection and Database Naming Conventions- Best practices

MongoDB Naming style MongoDB Naming Standards and Guidelines MongoDB Collection Naming

In this post, we will learn MongoDB Collection and Database Naming that can be used for MongoDB Database, Collection, and Field namings.

Naming standards are always helpful in the long run for any enterprise.

Naming standard brings uniformity, avoid ambiguity, and importantly when we talk about the seamless integration of information across the enterprise, standards and naming conventions makes our life easy.

We shall cover naming standards for the below,

It’s important we talk in the same language and conventions for data communication as a whole and what we do within the enterprise.

Below discussed naming conventions and examples will help you and guide you for a better understanding of naming, their limitation, and anti-patterns, etc.

MongoDB Database Naming Standards

Guidelines

  • Use Camel Casing or Lower Casing as required.

  • Use alpha-numeric characters [a-z 0-9]

  • Database names are case-sensitive.

  • Due to case sensitivity, I preferred to use lowercase to avoid any issues. (Ex. OS – Linux).

  • Database names must have fewer than 64 characters.

  • Database names for the Windows operating system,
    • Database names should contain alphanumeric characters.
    • Below special symbols below are not allowed on Windows OS.

Symbols not allowed in Database names   : / \ .  " $ * < > : | ?

  • Database names for Linux/Unix operating system
    • Database names should contain alphanumeric characters
    • The below special symbols are not allowed on Linux/Unix OS.

Symbols not allowed in Database names : / \ .  " $

  • Database names cannot be empty.

  • Database names should not contain null or space characters or an empty string.

  • Always try using some separator to make the name more readable.

Example

With “_” separator 

(lower case):   account_personal ,   account_saving
(Camel case):  Account_Personal,   Account_Saving

With “-” separator 

(lower case):   account-personal, account-saving
(Camel case):  Account-Personal, Account-Saving

Without any separator 

(lower case):   accountpersonal, accountsaving
(Camel case):  AccountPersonal, AccountSaving

Note: You may like to extend the above pattern to add more fields like Org names or domain or subdomain names if following DDD (Domain-Driven Design) like org names etc.

Example: Microsoft-Account-Personal

MongoDB Collection Naming

Guidelines

  • Use Camel-casing or lowercase names. It is preferred to use a lowercase to avoid any unwanted problems with the casing.

  • Collection names should not begin with special characters like
    • $
    • an empty string (e.g. “” ) or
    • contain the null character
    • prefixed with System. (As it is reserved).

  • Try using some separators to make the name more readable. I always preferred “_” as a separator. But you are free to choose your separator.

With “_” separator 

(lower case): account_record, credit_history
(Camel case):  Account_Record,Credit_History

With “-” separator

(lower case): account-record, credit-history
(Camel case):  Account-Record, Credit-History

Without separator

(lower case): accountrecord, credithistory
(Camel case):  AccountRecord, CreditHistory

  • The maximum length of the collection namespace should be equal to or less than 120 bytes.

account_personal.credit_history <= 120 bytes.

Note: You can extend the above pattern to add more names like module or domain names etc.

MongoDB Field Names Conventions

Guidelines

  • Use Camel case, Pascal case, or Lower case.

  • Field names can not contain the
    • null character or
    • empty string or
    • “.”

  • Field names can not start with the dollar sign $ character
    • Note: MongoDB 3.6 onwards the server permits the storage of field names that contain dots (i.e. . ) and dollar signs (i.e. $).

  • One can avoid using any separator for the field names. Especially if you are creating/automating model entities from JSON schema then having separators in the fields name can create confusion. (If doing schema modeling).

  • Sometimes “-” or “_” might flag as coding issues if mapped to code directly. Although the same issue can be avoided by using Named Property or Data annotation or Fluent API mapping (feature if exist any like Entity framework scaffolding). Again this is just my personal suggestion, but you are free to choose a separator if needed.

  • MongoDB doesn’t support duplicate field names.

Camel Case

Example: "name", "city," "account", "lastName" , "accountNumber"

Pascal case

 Example: "Name", "City," "Account", "LastName" ,"AccountNumber"

Lower case

 Example: "name", "city," "account", "lastname" ,"accountnumber"

Sample JSON example using camel case field names,

{ 
  "_id" : "01001", 
  "name" : "TheCodeBuzz", 
  "lastName" : "TheCodeBuzz", 
  "city" : "newyork", 
  "state" : "NY",
  "accountName" :"TEST",
  "accountNumber":"123"
}

Could we improve the above naming conventions further?

Do you have any better suggestions? Please sound off your comments below.

Additional references :

Summary

Naming standards bring uniformity, avoid ambiguity, and allow us to do seamless integration of information across the enterprise.

We can follow naming conventions for Database Instance names, Collection names, and Field names easily which will help us maintain uniformity, data quality, and governance around it.


Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published(2024) best practices and guidelines for software design and development.