String and number types in MongoDB - Deep Dive

Overview - String and number types

What is it?

In MongoDB, string and number types are ways to store text and numeric data in documents. Strings hold sequences of characters like words or sentences. Numbers can be integers or decimals and represent quantities or counts. These types help organize and query data effectively.

Why it matters

Without clear types for strings and numbers, data would be confusing and hard to use. For example, searching for a name or calculating totals would be unreliable. Proper types let MongoDB store, sort, and compare data correctly, making apps faster and more accurate.

Where it fits

Before learning string and number types, you should understand basic MongoDB documents and collections. After this, you can learn about more complex types like arrays and embedded documents, and how to query and index data efficiently.

Mental Model

Core Idea

Strings store text exactly as typed, while number types store numeric values in different sizes and formats to balance precision and storage.

Think of it like...

Think of strings as words written on paper, and numbers as measuring cups of different sizes—some hold whole cups, others can measure tiny fractions precisely.

┌───────────────┐       ┌───────────────┐
│   String      │       │   Number      │
│ (text data)   │       │ (numeric data)│
│ "Hello"      │       │ 42 (int32)    │
│ "MongoDB"   │       │ 3.14 (double) │
└───────────────┘       └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding MongoDB Strings

Concept: Strings are sequences of characters stored as text in MongoDB documents.

Strings in MongoDB are UTF-8 encoded text. They can hold letters, numbers, symbols, or spaces. For example, a field "name" might have the string value "Alice". Strings are enclosed in double quotes when written in queries or documents.

Result

You can store and retrieve text data like names, descriptions, or messages in MongoDB documents.

Knowing strings are UTF-8 means MongoDB supports many languages and symbols, making it flexible for global apps.

2

Foundation

Basic Number Types in MongoDB

Concept: MongoDB stores numbers using different types like int32, int64, and double to handle various numeric needs.

Numbers can be integers (whole numbers) or floating-point (decimals). MongoDB uses int32 for small integers, int64 for large integers, and double for decimals. For example, age might be int32: 30, while price might be double: 19.99.

Result

You can store numeric data precisely and efficiently depending on size and type.

Choosing the right number type saves space and ensures calculations are accurate.

3

Intermediate

Differences Between int32, int64, and double

🤔Before reading on: do you think int32 and int64 store decimal numbers or only whole numbers? Commit to your answer.

Concept: int32 and int64 store whole numbers of different sizes; double stores decimal numbers with floating precision.

int32 stores 32-bit signed integers (about ±2 billion), int64 stores 64-bit signed integers (much larger range), and double stores 64-bit floating-point numbers for decimals. Using int32 for small numbers is efficient, but large numbers need int64. Decimals require double.

Result

You can pick the best number type for your data size and precision needs.

Understanding these differences helps prevent data loss or errors when numbers exceed type limits.

4

Intermediate

How MongoDB Stores Strings and Numbers

🤔Before reading on: do you think MongoDB stores strings and numbers as plain text or in a special binary format? Commit to your answer.

Concept: MongoDB stores strings as UTF-8 text and numbers in binary formats optimized for size and speed.

Strings are stored as UTF-8 bytes, allowing international characters. Numbers are stored in binary formats: int32 and int64 as fixed-size binary integers, double as IEEE 754 floating-point. This makes reading and writing fast and compact.

Result

Data storage is efficient and supports fast queries and calculations.

Knowing storage formats explains why some number operations are faster and why strings support many languages.

5

Intermediate

Querying by String and Number Types

🤔Before reading on: do you think MongoDB treats the number 5 and the string "5" as the same when querying? Commit to your answer.

Concept: MongoDB distinguishes between strings and numbers in queries, so types must match for accurate results.

When querying, searching for the number 5 will not match the string "5". For example, {age: 5} finds documents where age is a number 5, but {age: "5"} looks for the string. This strict typing avoids confusion but requires careful query writing.

Result

Queries return precise matches based on data type, preventing errors.

Understanding type sensitivity in queries helps avoid bugs where data looks similar but is stored differently.

6

Advanced

Handling Number Precision and Rounding

🤔Before reading on: do you think MongoDB's double type can store all decimal numbers exactly? Commit to your answer.

Concept: Double uses floating-point representation, which can cause small rounding errors in decimal numbers.

Double stores numbers in binary floating-point, which cannot exactly represent some decimals (like 0.1). This can lead to tiny precision errors in calculations. For exact decimals, MongoDB 4.2+ supports Decimal128 type, but double remains common for most uses.

Result

You learn when to expect rounding errors and when to use special decimal types.

Knowing floating-point limits prevents surprises in financial or scientific data where exact decimals matter.

7

Expert

Impact of Type Choice on Indexing and Performance

🤔Before reading on: do you think indexing a string field is always as fast as indexing a number field? Commit to your answer.

Concept: Data type affects how MongoDB indexes and compares values, impacting query speed and storage.

Number fields often index faster and use less space than strings because numbers have fixed sizes and simple comparison rules. Strings vary in length and require more complex collation rules. Choosing the right type for frequently queried fields improves performance.

Result

You can optimize database speed and size by selecting appropriate types for indexed fields.

Understanding type impact on indexes helps design databases that scale efficiently under load.

Under the Hood

MongoDB stores data in BSON format, a binary form of JSON. Strings are stored as UTF-8 byte sequences with length prefixes. Numbers are stored in fixed-size binary formats: int32 (4 bytes), int64 (8 bytes), and double (8 bytes IEEE 754). This binary storage allows fast parsing and compact size. When querying, MongoDB compares values by type and value using BSON rules.

Why designed this way?

BSON was designed to balance human-readable JSON with efficient binary storage. Using fixed-size binary for numbers speeds up math operations and indexing. UTF-8 strings support international text. Alternatives like plain JSON would be slower and larger. BSON's design enables MongoDB to be fast and flexible.

┌───────────────┐
│   Document    │
│  (BSON data)  │
└──────┬────────┘
       │
┌──────▼────────┐       ┌───────────────┐
│   String      │       │   Number      │
│ UTF-8 bytes   │       │ Binary format │
│ Length + data │       │ int32/int64/double │
└───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think MongoDB treats the number 10 and the string "10" as equal in queries? Commit to yes or no.

Common Belief: Numbers and strings with the same characters are treated the same in queries.

Reality: MongoDB treats numbers and strings as different types; queries must match the exact type to find results.

Why it matters: Assuming they are equal causes queries to miss data or return empty results unexpectedly.

Quick: Do you think MongoDB's double type stores decimal numbers exactly? Commit to yes or no.

Common Belief: Double type stores decimal numbers exactly without any rounding errors.

Reality: Double uses floating-point representation, which can introduce small rounding errors for some decimals.

Why it matters: Ignoring this can cause subtle bugs in financial or scientific calculations needing exact decimals.

Quick: Do you think indexing a string field is always as fast as indexing a number field? Commit to yes or no.

Common Belief: All data types index equally fast in MongoDB.

Reality: Number fields usually index faster and use less space than strings due to fixed size and simpler comparisons.

Why it matters: Choosing string types for large indexed numeric data can slow queries and increase storage.

Quick: Do you think MongoDB automatically converts number types when storing data? Commit to yes or no.

Common Belief: MongoDB automatically converts numbers between int32, int64, and double as needed.

Reality: MongoDB stores numbers exactly as given; it does not convert between number types automatically.

Why it matters: This can cause unexpected query misses or storage bloat if types are inconsistent.

Expert Zone

1

MongoDB's Decimal128 type offers exact decimal storage but uses more space and slower math operations compared to double.

2

String collation settings affect sorting and comparison, which can impact query results and index usage.

3

Storing numbers as strings to preserve formatting (like phone numbers) can cause inefficient queries and indexing.

When NOT to use

Avoid using string types for numeric data that requires calculations or sorting; use appropriate number types instead. For exact decimal needs like currency, prefer Decimal128 over double. If data is large text or unstructured, consider other types like arrays or embedded documents.

Production Patterns

In production, numeric fields like prices or counts use int32 or int64 for efficiency. Text fields like names use strings with proper collation. Decimal128 is used in financial apps to avoid rounding errors. Indexes are designed considering type size and query patterns to optimize performance.

Connections

Data Types in Programming Languages

MongoDB's string and number types correspond to common programming language types like string, int, float.

Understanding programming data types helps grasp MongoDB types since data moves between app code and database.

Character Encoding (UTF-8)

MongoDB strings use UTF-8 encoding, the same standard used in web and software text handling.

Knowing UTF-8 explains how MongoDB supports international text and why some characters take more storage.

Floating-Point Arithmetic in Computer Science

MongoDB's double type uses IEEE 754 floating-point standard common in computing for decimal numbers.

Understanding floating-point limits clarifies why some decimal numbers can't be stored exactly and how to handle rounding.

Common Pitfalls

#1 Querying numbers as strings causes no matches.

Wrong approach:

{ age: "30" }

Correct approach:

{ age: 30 }

Root cause:

Confusing string and number types leads to queries that look correct but fail because types differ.

#2 Storing decimal numbers as double causes rounding errors.

Wrong approach:

{ price: 19.999999999999999 } // stored as double

Correct approach:

{ price: NumberDecimal("19.999999999999999") }

Root cause:

Using double for precise decimals ignores floating-point limitations; Decimal128 is needed for exactness.

#3 Using int32 for very large numbers causes overflow.

Wrong approach:

{ count: 3000000000 } // int32 max is ~2 billion

Correct approach:

{ count: NumberLong(3000000000) }

Root cause:

Not knowing int32 limits causes data corruption or errors; int64 (NumberLong) is needed for large integers.

Key Takeaways

MongoDB stores text as UTF-8 strings and numbers in different binary formats for efficiency and precision.

Choosing the correct number type (int32, int64, double, Decimal128) is crucial for data accuracy and storage optimization.

Queries in MongoDB are type-sensitive; numbers and strings with the same characters are not interchangeable.

Floating-point numbers (double) can introduce rounding errors; use Decimal128 for exact decimal values.

Data type choice affects indexing speed and storage size, impacting overall database performance.