THE SHORT ANSWER
A relational database organizes persistent data into tables. Each row is a record, columns define fields, and identifiers connect related records. Other databases organize information differently. A spreadsheet is a flexible document for analysis; a CMS manages publishing; neither term is interchangeable with database.
Model things and their relationships
| Table | Example fields | Relationship |
|---|---|---|
| users | id, name, email | One user can have registrations |
| programs | id, title, capacity | One program can receive registrations |
| registrations | id, user_id, program_id, status | Connects a user to a program |
| payments | id, registration_id, provider_reference, status | Connects a payment state to a registration |
Identifiers distinguish records; relationships let the system ask which registrations belong to a user or program without copying every detail repeatedly.
Evidence & context: PostgreSQL Global Development Group
Persistent data survives the current screen
A typed value in a form exists temporarily until the product stores it. Persistent information remains available across requests, sessions or devices according to the product's rules. Storage design must consider correction, deletion, retention and recovery.
Structured data follows defined fields and relationships, such as an order with a customer, amount and status. Unstructured data such as free-form documents, images or recordings needs different storage, search and access decisions even when a database keeps its metadata.
Database, spreadsheet and CMS serve different jobs
| System | Strength | Limit to notice |
|---|---|---|
| Database | Structured application records and relationships | Requires schema, access and operational controls |
| Spreadsheet | Flexible human analysis and small workflows | Concurrent rules and application integrity can become fragile |
| CMS | Editorial content and publishing workflow | Not a general replacement for transactional application data |
Store less, protect it deliberately
- Collect only data needed for a stated purpose.
- Choose fields and relationships before building forms.
- Validate types and required values.
- Restrict who can read or change each record.
- Plan backup, export, retention and deletion.
- Avoid using live sensitive data in prototypes or tests.
Data quality and access rules are product requirements. Continue with authentication and permissions.
Evidence & context: NIST · UK Information Commissioner's Office
Sources & further reading
- PostgreSQL tutorial: SQL language and relational concepts
PostgreSQL Global Development Group. Official relational-database documentation covering tables, rows, queries and joins. The module uses the durable concepts without prescribing PostgreSQL or teaching SQL.
- Secure Software Development Framework
NIST. Outcome-based secure-development guidance covering preparation, protection, secure production and vulnerability response. It is a framework, not a product-specific checklist.
- How should we assess security and data minimisation in AI?
UK Information Commissioner's Office. UK regulatory guidance, checked 11 September 2026. Jurisdiction-specific context, not individual legal advice or permission for a particular use.
Examples and exercises are illustrative unless attributed to a source. No independent expert review is claimed.
A correction, a counterexample or an experience worth sharing?
Join the conversation ↗