String Data Type and String Handling

The BSON string type represents textual data such as names, email addresses, titles, descriptions, slugs, and category labels.

Example document:

{
 name: "Meera",
 email: "meera@example.com",
 role: "developer",
 country: "India"
}

String values are enclosed in quotation marks in shell examples. MongoDB stores the string content as BSON string data.

Equality matching

db.users.find({ role: "developer" });

This matches documents whose role value equals the string developer, subject to the applicable collation rules.

Case sensitivity

String comparisons are normally case-sensitive under the default simple binary comparison behavior.

For example, these values are different under ordinary simple collation:

"MongoDB"
"mongodb"
"MONGODB"

If your application requires case-insensitive comparisons, consider an appropriate collation or a normalized field, depending on the query pattern and indexing requirements.

String length

A string can contain a single character or a long description. MongoDB supports string operators in queries and aggregation expressions, including operations for transforming or examining string content.

For example, an aggregation can calculate the string length of a title:

db.courses.aggregate([
 {
 $project: {
 title: 1,
 titleLength: { $strLenCP: "$title" }
 }
 }
]);

$strLenCP counts Unicode code points rather than UTF-8 bytes. This distinction matters when strings contain non-ASCII characters.

Normalization considerations

A user may enter Arun, arun, or ARUN. Whether those values should be considered equivalent depends on the application's requirements.

For usernames or email lookup, define a consistent normalization strategy. A normalized field can simplify lookups and indexing, but normalization rules should be applied consistently during both writes and queries.

Do not blindly lowercase every string. Names, passwords, tokens, identifiers, and natural-language text have different semantics.

Strings that contain numbers

Avoid storing numeric data as strings when numeric comparisons or arithmetic are required.

For example:

{ price: "100" }

is not equivalent to:

{ price: 100 }

Use strings for identifiers whose meaning is textual, such as postal codes or phone numbers, even if they contain only digits. Use numeric types when the value is genuinely a quantity.

Insert and query string fields

db.stringExamples.insertMany([
 { name: "Arun", role: "developer" },
 { name: "Meera", role: "Developer" },
 { name: "Ravi", role: "admin" }
]);

// Exact string match under the collection's applicable collation.
db.stringExamples.find({ role: "developer" });

// Inspect string lengths using aggregation.
db.stringExamples.aggregate([
 {
 $project: {
 name: 1,
 role: 1,
 roleLength: { $strLenCP: "$role" }
 }
 }
]);

💡 The example demonstrates string equality and string-length calculation. Under simple collation, developer and Developer do not match each other. $strLenCP counts Unicode code points and is useful when measuring text length without counting UTF-8 bytes.

Key Takeaways

Strings represent textual values.
Default string matching is case-sensitive under simple collation.
Collation can change string comparison behavior.
String normalization should follow the meaning of the field.
Store identifiers as strings when they represent labels rather than quantities.

Knowledge Check

Under simple collation, what happens when querying `{ role: "developer" }` against a document containing `{ role: "Developer" }`?