MongoDB Fields and Types: Essential Basic Data Types You Must Know

MongoDB is a popular document - oriented database that uses JSON - style documents (BSON) as the data storage unit. Unlike relational databases (such as MySQL) which use tables and fixed columns, each document in MongoDB can have its own unique fields, and the field types are also very flexible. However, this does not mean that “arbitrary definition” is acceptable. Understanding and correctly using the basic data types of MongoDB is the key to designing efficient and maintainable data structures. Today, we will discuss the essential basic field types in MongoDB to help you lay a solid foundation for data design.

One of the core advantages of MongoDB is its “dynamic structure”, which means that different documents can have different fields, and the same field can even store different types of data in different documents (but this is not recommended). However, choosing the appropriate field type reasonably can make the data easier to manage, queries faster, and indexes more efficient.

Common Basic Data Types¶

1. String¶

The string type is used to store text data, such as names, emails, addresses, etc., and it uses UTF - 8 encoding. In MongoDB, strings are enclosed in double quotes.

Example:

{
  "name": "Zhang San",       // Store the name (string type)
  "email": "zhangsan@example.com"  // Store the email address
}

Note: If you need to store ID - like numbers (such as user IDs), although you can use strings, it is more recommended to use integer types (such as Int32/Int64) because integer sorting and comparison are more efficient.

2. Integers (Int32, Int64)¶

MongoDB provides dedicated integer types, divided into 32 - bit (Int32) and 64 - bit (Int64), which are used to store non - fractional integer values.

Example:

{
  "age": 25,           // Int32 type (default integer type)
  "user_id": NumberInt("10001"),  // Explicitly specify Int32 type
  "order_id": NumberLong("1234567890123456789")  // Explicitly specify Int64 type
}

Note: If you directly write a number (such as 25), MongoDB will store it as a double - precision floating - point number by default (similar to JavaScript’s Number). However, for integer operations, it is recommended to use a dedicated integer type to avoid precision loss.

3. Boolean¶

A boolean value has only two possible values: true or false, and it is used to represent logical judgments such as “yes/no” and “exists/does not exist”.

Example:

{
  "isActive": true,    // Whether the user is active
  "hasPaid": false     // Whether the payment has been made
}

4. Date¶

The date type is used to store time information. In MongoDB, it is stored in UTC (Coordinated Universal Time) with a precision of milliseconds, and internally represented by the number of milliseconds since 00:00:00 UTC on January 1, 1970.

Example:

{
  "createdAt": new Date("2023-01-15T08:30:00Z"),  // Explicitly create a date
  "updatedAt": ISODate("2023-02-20T14:45:00Z")     // Another way to write it
}

Note: The date type cannot be stored as a string (unless manually converted). It must be stored as MongoDB’s Date type to use date operators (such as $dateAdd and $expr).

5. Array¶

The array type is used to store ordered list data. The elements in the array can be of any type (strings, numbers, objects, etc.), and even nested arrays are allowed.

Example:

{
  "hobbies": ["reading", "coding", "hiking"],  // String array
  "scores": [90, 85, 95],                      // Number array
  "addresses": [                               // Nested object array
    { "city": "Beijing", "zip": "100000" },
    { "city": "Shanghai", "zip": "200000" }
  ]
}

Note: The length of the array can change dynamically, and array operators such as $push and $pull are supported. However, complex arrays may require more complex filtering conditions.

6. Document/Object¶

MongoDB supports nested documents (similar to JSON objects), where the value of a field is itself a document, which is used to represent complex structured data.

Example:

{
  "user": {                  // Nested document
    "name": "Li Si",
    "age": 30,
    "contact": {             // One more level of nesting
      "phone": "13800138000",
      "email": "lisi@example.com"
    }
  },
  "tags": { "type": "user", "status": "active" }  // Simple object
}

Note: Avoid excessive nesting of documents (it is recommended not to exceed 3 levels), otherwise it will affect query efficiency. When fields are frequently queried, you may consider using a relational database with associated tables.

7. Null¶

null indicates that the value of a field is empty or does not exist. It is different from “undefined” and null is an explicit empty value.

Example:

{
  "address": null,          // The address field is empty
  "lastLogin": null         // The last login time is empty
}

Note: null means the field exists but the value is empty, while the absence of the field (no key in {}) means the field does not exist. These two cases need to be distinguished.

8. Other Basic Types¶

• ObjectId: Each document by default contains an _id field of type ObjectId, which is used to uniquely identify the document and contains a timestamp and machine identifier, ensuring uniqueness.
• Binary Data: Used to store binary data (such as images). For small data, the Binary type can be used, and for large files, GridFS is recommended.
• Regular Expression (Regex): Stores regular expression objects for string matching queries (such as { "name": { $regex: "^张" } }).

Best Practices for Field Types¶

1. Type Consistency: Keep the same type for the same field across all documents (for example, age should always store integers and not be mixed with strings), otherwise it will affect queries and indexes.
2. Explicit Numerical Types: Use Int32/Int64 to store numbers and Date to store time to avoid implicit conversion.
3. Avoid Excessive Nesting: Excessively nested documents will increase query complexity. They can be split into independent fields or use relational tables.
4. Prioritize Numerical/Date Types for Indexed Fields: For indexed fields, choose integer or date types. String indexes are less efficient.

Summary¶

The field types of MongoDB are the core of data model design. Understanding and correctly selecting types (such as strings, integers, booleans, dates, arrays, objects, etc.) can make the data clearer and queries more efficient. Remember: the choice of type should be combined with business scenarios, and maintaining consistency and simplicity is the key. After mastering these basics, you will be better able to handle data storage and operations in MongoDB!