Storage classifications
Databases can be classified along three axes:
By medium
| Type | Description |
|---|
| In-core | Data held entirely in primary memory (RAM). Fast, but capacity-limited and ephemeral. |
| Secondary storage | Data held on disk or SSD. Persistent, high capacity, but slower access. |
By persistence
| Type | Description |
|---|
| Ephemeral | Data disappears when the process exits or the machine loses power. |
| Persistent | Data survives process termination and power cycles. |
By scale
| Type | Description |
|---|
| In-core (big data fits) | The entire dataset can reside in RAM. Simplifies design. |
| Big data | The dataset exceeds available RAM. Requires careful management of what is in memory and what is on disk. |
Write patterns
| Pattern | Characteristics | Example use case |
|---|
| Read-optimised | Data rarely changes; heavy read traffic. Indexes built aggressively. | Reference data, product catalogues |
| Transaction-optimised | Many concurrent queries and updates. Locking and logging dominate. | Banking, ticket booking |
| Append-only journal | Data is never overwritten; only appended. Old state preserved. | Audit logs, event sourcing |
Consistency models
ACID (strong consistency)
Atomicity, Consistency, Isolation, Durability. Every transaction is an indivisible unit: it either completes entirely or has no effect. After a transaction commits, all subsequent reads see its effects. This is the traditional model in relational DBMSs.
BASE (relaxed consistency)
Basically Available, Soft state, Eventual consistency. The system may not be immediately consistent after an update, but if updates cease, all replicas will eventually converge. This model is common in distributed NoSQL systems.
| Property | ACID | BASE |
|---|
| Consistency | Strong, immediate | Eventual |
| Availability | May block during partitions | Prioritised |
| Complexity | Higher for the DBMS | Higher for the application |
| Typical use | Financial transactions | Social media, content delivery |
Data arrangement
| Model | Structure |
|---|
| Relational | Data in tables with rows and columns. Schema enforced. |
| Semi-structured (document) | Data as nested documents (JSON, XML). Schema flexible or absent. |
| Graph | Data as nodes and edges. Rich support for path-oriented queries. |
Consistency checks
A DBMS can enforce several kinds of constraint:
| Check | Description | Example |
|---|
| Value range | A field’s value must fall within a specified domain | weight cannot be negative |
| Foreign key referential integrity | A value referencing another record must point to something that exists | A patient’s GP must exist in the Doctors table |
| Value atomicity | Each field holds one piece of information | Do not cram two street names into a single address field |
| Entity integrity | Every row must be identifiable | No row may have a NULL primary key |
Summary
- Databases are classified by storage medium (in-core vs. secondary), persistence (ephemeral vs. persistent), and scale.
- Write patterns range from read-optimised to append-only.
- ACID provides strong guarantees; BASE trades consistency for availability and partition tolerance.
- Consistency checks — domain, referential, atomicity, entity — protect data quality.