Data Management for Web Applications

Introduction and Context

Modern web applications are data-intensive systems. They collect user input, maintain business records, support search and reporting, coordinate concurrent activity, and preserve evidence of past events. The quality of a web application therefore depends not only on its user interface and application logic, but also on how reliably and efficiently it stores, retrieves, validates, secures, and evolves data.

Data management for web applications involves more than selecting a database product. It requires decisions about data models, consistency, transaction boundaries, schema evolution, query performance, caching, search, validation, availability, recovery, and governance. A relational database may be appropriate for financial transactions, while a document database may suit variable product attributes and a key-value store may support sessions or rate limits. Professional design is consequently an exercise in matching data characteristics and workload requirements to suitable persistence strategies.

This chapter examines relational, document, and key-value models; SQL and NoSQL principles; transactions and consistency; object-relational and object-document mapping; migrations; indexing; caching; search; validation; and resilient persistence. It also considers the limitations and governance responsibilities associated with these technologies.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Compare relational, document, and key-value data models.

2. Design tables, documents, constraints, and indexes for web workloads.

3. Explain transactions, isolation, consistency models, and concurrency anomalies.

4. Select and use ORM and ODM approaches critically.

5. Plan safe schema migrations and data backfills.

6. Design caching and search integrations without compromising correctness.

7. Apply layered data validation and resilient persistence patterns.

8. Evaluate security, privacy, compliance, operational, and ethical implications.

1. Data as a Design Concern

A useful data design begins with the domain rather than with a database brand. Designers identify entities, attributes, relationships, invariants, access patterns, lifecycle rules, and retention requirements. An invariant is a condition that must remain true, such as “an order must contain at least one line item” or “a payment cannot be recorded twice for the same payment provider event.”

Three questions are especially important:

• What facts must be stored permanently?
• Which queries and updates must be fast and reliable?
• Which rules must be enforced by the database, by application code, or by both?

Data has several qualities that must be considered together. Persistence concerns survival across process failures. Integrity concerns correctness and adherence to rules. Availability concerns access during failures. Confidentiality concerns protection from unauthorized disclosure. Durability concerns whether committed data survives a failure. These qualities can conflict: extensive synchronous replication may improve durability but increase write latency; aggressive caching may improve speed but create stale results.

A workload should be characterized by read/write proportions, request rates, query complexity, record size, transaction scope, growth rate, latency targets, retention period, and failure tolerance. A design optimized for a reporting system may be unsuitable for a high-volume session store.

2. Relational Data Management

2.1 Relational foundations

The relational model represents data as relations, commonly implemented as tables. A table consists of rows and named columns. A primary key uniquely identifies each row. A foreign key expresses a reference to a key in another table and supports referential integrity. A candidate key is any minimal attribute set that uniquely identifies a row; one candidate key is selected as the primary key.

Consider a commerce system with Customer, Order, and OrderItem relations:

```sql

CREATE TABLE customer (

customer_id BIGINT PRIMARY KEY,

email VARCHAR(320) NOT NULL UNIQUE,

created_at TIMESTAMP NOT NULL

);

CREATE TABLE orders (

order_id BIGINT PRIMARY KEY,

customer_id BIGINT NOT NULL,

status VARCHAR(20) NOT NULL,

total_amount DECIMAL(12,2) NOT NULL,

created_at TIMESTAMP NOT NULL,

FOREIGN KEY (customer_id) REFERENCES customer(customer_id),

CHECK (total_amount >= 0)

);

CREATE TABLE order_item (

order_id BIGINT NOT NULL,

product_id BIGINT NOT NULL,

quantity INTEGER NOT NULL CHECK (quantity > 0),

unit_price DECIMAL(12,2) NOT NULL CHECK (unit_price >= 0),

PRIMARY KEY (order_id, product_id),

FOREIGN KEY (order_id) REFERENCES orders(order_id)

);

```

This design separates customers, orders, and order items, avoids repeated customer data, and uses constraints to protect basic invariants. Monetary values use a fixed-precision decimal type rather than binary floating point, because binary floating point can represent some decimal values only approximately.

2.2 Normalization and controlled denormalization

Normalization reduces redundancy and update anomalies. In simplified terms, first normal form requires atomic values and a well-defined row structure; second normal form removes dependencies on only part of a composite key; third normal form generally removes non-key attributes that depend on other non-key attributes. Normalization is not an absolute requirement for every workload. It improves integrity and maintainability, but joins may increase read cost.

Denormalization deliberately duplicates or precomputes data to improve read performance. For example, an order may store the customer’s shipping address as a snapshot because the customer’s current address must not alter the historical order. This is not merely a performance optimization; it represents a domain decision about historical truth. Other denormalized data, such as a cached order total, requires a clear update strategy.

2.3 SQL query design

SQL expresses data retrieval declaratively. A query planner selects an execution strategy, such as an index scan, table scan, hash join, or merge join. Developers should inspect execution plans for expensive queries rather than assuming that an index will always help.

An index is an auxiliary data structure that accelerates selected access paths at the cost of storage and write overhead. A composite index on `(customer_id, created_at)` is useful for queries filtering by customer and ordering or filtering by date. Its usefulness depends on the database engine and the leftmost access pattern; it is not automatically equivalent to separate indexes on both columns.

Indexes should be designed from measured query patterns. Excessive indexing slows inserts and updates, increases storage consumption, and may confuse optimization. Selectivity, cardinality, sort requirements, and data distribution matter. A column with only two values may provide little benefit as a standalone index unless combined with other predicates or supported by a partial index.

3. Document and Key-Value Models

3.1 Document databases

A document database stores records as self-contained documents, commonly represented with JSON-like structures. A product document might be:

```json

{

"productId": "P-1042",

"name": "Travel Backpack",

"price": 89.95,

"attributes": {

"capacityLitres": 32,

"waterproof": true

},

"tags": ["travel", "outdoor"]

}

```

Documents are attractive when aggregates are usually read and written together, when attributes vary by category, or when rapid domain evolution is expected. Embedded data can avoid joins. However, embedding large or frequently changing collections can cause document growth, contention, and difficult partial updates. Referencing separate documents may be preferable when data is shared, independently owned, or unbounded.

Document design is access-pattern oriented. A document should represent a meaningful aggregate boundary, not simply reproduce object classes. Duplication is acceptable only when ownership, update frequency, and consistency consequences are understood. Schema flexibility does not eliminate schema design: documents still require validation, versioning, and migration policies.

3.2 Key-value stores

A key-value store maps a unique key to an opaque or semi-structured value. It is well suited to sessions, feature flags, temporary tokens, counters, idempotency records, and cache entries. Typical operations are direct reads and writes by key. Querying by arbitrary attributes is usually limited or expensive compared with a relational database.

Key design is critical. Keys should encode an unambiguous namespace and identifier, such as `session:user:8472` or `rate:user:8472:2025-03-08`. Time-to-live settings can automatically remove temporary data, but expiration is not a substitute for durable archival. Atomic increments and conditional writes are useful for counters and coordination, but distributed locking requires careful analysis of lease expiry, clock behavior, and failure modes.

3.3 Polyglot persistence

Polyglot persistence uses different storage technologies for different responsibilities. A relational database may be the system of record for orders, a document store may support catalog content, a key-value store may hold sessions, and a search engine may serve full-text queries. This approach can improve fitness for purpose, but it increases operational complexity, data duplication, observability requirements, backup responsibilities, and consistency challenges. Each additional datastore should have a justified ownership and recovery plan.

4. Transactions, Consistency, and Concurrency

4.1 ACID properties

A transaction is a logical unit of work. The traditional ACID properties are:

• Atomicity: all intended changes occur, or none do.
• Consistency: committed transactions preserve defined integrity rules.
• Isolation: concurrent transactions do not produce prohibited observations.
• Durability: committed changes survive specified failures.

ACID does not mean that every database provides identical behavior. Isolation levels differ, durability depends on configuration and replication, and application-defined invariants may require explicit constraints or locking.

4.2 Isolation and anomalies

Concurrent operations can produce anomalies. A dirty read observes uncommitted data. A non-repeatable read obtains different values for the same row during one transaction. A phantom read observes newly inserted or removed rows matching a repeated predicate. A lost update occurs when one write overwrites another without incorporating it.

Common isolation levels include read uncommitted, read committed, repeatable read, and serializable. Their exact behavior is database-specific. Serializable isolation aims to produce results equivalent to some serial ordering of transactions, but can reduce concurrency and cause retries or serialization failures. Snapshot or multi-version approaches can provide consistent reads while allowing some concurrent writes, but they do not automatically protect every business invariant.

A web request should keep a transaction as short as practical. External network calls, user interaction, and lengthy computation generally should not occur inside a database transaction. When a workflow spans multiple systems, a distributed transaction may be undesirable or unavailable. Alternatives include an outbox pattern, idempotent consumers, compensating actions, and explicit state machines.

4.3 Idempotency and the outbox pattern

An operation is idempotent if repeating it produces the same intended effect as performing it once. HTTP PUT is conceptually idempotent when designed appropriately; payment creation usually requires an idempotency key to prevent duplicate charges after retries.

In the outbox pattern, the application writes a business change and an event record in the same local database transaction. A separate publisher reads the outbox and sends events to a message broker, marking them as published or retrying them. Consumers must still tolerate duplicate delivery, because publication and acknowledgement can fail at different points. This pattern provides reliable communication without requiring a distributed two-phase commit, but it introduces eventual consistency and operational monitoring requirements.

5. ORM and ODM Technologies

An object-relational mapper (ORM) maps application objects to relational tables. An object-document mapper (ODM) performs a similar role for documents. These tools reduce repetitive SQL or serialization code and may provide migrations, relationship handling, validation hooks, and query composition.

However, mappings can conceal important database behavior. Common problems include:

• N+1 queries: retrieving a collection and then issuing one query per related object.
• Over-fetching: selecting more columns or nested data than required.
• Under-fetching: requiring many round trips to construct a response.
• Accidental eager loading: loading large graphs unnecessarily.
• Unclear transaction boundaries: assuming an ORM method is automatically atomic.
• Unsafe dynamic queries: interpolating untrusted values into raw query fragments.

Professional ORM use requires examining generated SQL, defining fetch strategies deliberately, using parameterized queries, selecting only needed fields, and measuring performance under realistic data volumes. ORMs are not substitutes for relational knowledge. Complex reporting, bulk operations, window functions, and database-specific features may be clearer and faster in carefully reviewed SQL.

An ODM likewise should not encourage uncontrolled document growth or treat schema flexibility as permission to omit validation. Domain constraints must remain explicit.

6. Schema Migrations and Evolution

A migration is a controlled change to database structure or data. Typical changes include adding a nullable column, creating an index, splitting a field, changing a representation, or removing obsolete data.

A safe deployment often follows an expand-and-contract sequence:

1. Expand the schema in a backward-compatible way.

2. Deploy application code that can read both old and new representations.

3. Begin writing the new representation, possibly dual-writing temporarily.

4. Backfill existing records in controlled batches.

5. Verify completeness and correctness.

6. Switch reads to the new representation.

7. Remove the old field or behavior in a later release.

Large migrations should consider lock duration, replication lag, transaction log growth, throttling, resumability, and rollback strategy. A migration that runs successfully on a small development database may disrupt production traffic. Destructive changes should be separated from application releases when rollback may be required.

Migration files should be version-controlled, deterministic, observable, and tested against representative data. Data backfills should be idempotent or checkpointed. If a transformation is irreversible, backups and restoration procedures must be validated before execution.

7. Validation, Security, and Governance

Validation should occur at multiple layers. Client-side validation improves usability but cannot be trusted. API validation checks syntax, types, ranges, authorization context, and cross-field rules. Database constraints provide a final integrity boundary for conditions the database can express.

Input must be treated as untrusted. Parameterized queries prevent SQL injection; equivalent safe APIs are required for document queries. Output encoding, authorization checks, secret management, and least-privilege database accounts are essential. An application should not use a database administrator account for ordinary requests.

Authorization is distinct from authentication. A user may be authenticated but still not authorized to access a particular tenant, order, or document. Query predicates should enforce tenant and ownership boundaries close to the data access layer. Logging must avoid exposing passwords, tokens, full payment details, or unnecessary personal information.

Data governance includes classification, retention, access review, lineage, deletion, and lawful processing. Privacy principles such as data minimization and purpose limitation reduce risk. Regulatory requirements vary by jurisdiction and sector, but organizations commonly need controls for access rights, breach response, retention, auditability, and cross-border transfer. Encryption in transit and at rest reduces exposure but does not replace authorization or key management.

8. Caching and Search

8.1 Caching strategies

A cache stores a representation closer to the consumer to reduce latency or database load. Common patterns include:

• Cache-aside: the application reads the cache; on a miss it loads from the database and populates the cache.
• Read-through: the cache layer loads missing values through a configured data source.
• Write-through: writes update the cache and underlying store together through the cache layer.
• Write-behind: the cache acknowledges a write before persistence, increasing risk if the cache fails.

Cache-aside is flexible but creates invalidation challenges. A practical cache key should include resource identity and relevant version or tenant information. Time-to-live limits stale data duration, but a TTL is not proof of freshness. Explicit invalidation is often needed after important writes. Stampedes occur when many requests rebuild an expired item simultaneously; jittered expiration, request coalescing, or stale-while-revalidate techniques can reduce this effect.

Never cache sensitive data without considering isolation, encryption, eviction, and access controls. A cache outage should normally degrade performance rather than destroy correctness. The source of truth must remain identifiable.

8.2 Search systems

Search engines build specialized indexes, such as inverted indexes, to support token, phrase, relevance, and faceted queries. They are useful for full-text search and discovery but are often not the authoritative transactional store. Search indexes are commonly updated asynchronously, so users may observe eventual consistency.

Search design includes analyzers, tokenization, stemming, language handling, ranking, synonyms, typo tolerance, and access filtering. Security filters must be applied as part of the search query, not merely after results are returned, because post-filtering may expose counts or metadata. Indexes require reindexing procedures, versioning, capacity planning, and monitoring of indexing lag.

9. Resilient Persistence and Operations

A resilient persistence design assumes failure. Relevant failure modes include connection exhaustion, deadlocks, timeouts, replica lag, disk failure, partial network loss, corrupted records, and incompatible deployments.

Connection pools should be bounded. Unbounded retries can amplify an outage; retries should be limited, use exponential backoff with jitter, and occur only for operations safe to retry. Timeouts must be explicit at client, query, and request levels. Deadlocks may be retried when the transaction is known to be safe, but repeated deadlocks indicate a design problem such as inconsistent lock ordering.

Backups are meaningful only when restoration is tested. Recovery planning should define recovery point objective (RPO), the maximum acceptable data loss measured in time, and recovery time objective (RTO), the target time to restore service. These are operational objectives rather than universal formulas. Replication improves availability and read scale but is not a complete backup strategy; replicated deletion or corruption can spread to replicas.

Observability should include query latency, error rates, connection utilization, lock waits, cache hit ratio, replication lag, storage growth, migration progress, and data-quality failures. Distributed tracing helps associate a slow web request with a database query or downstream search call. Alerts should be tied to user impact and actionable thresholds.

10. Applied Case: Illustrative Multi-Tenant Learning Platform

Background

Consider an illustrative postgraduate learning platform serving universities and corporate clients. It manages users, courses, enrollments, assessments, submissions, notifications, and search across course content. Each organization must see only its own data.

Problem

The initial system stores all information in a single document collection. Course documents contain embedded submissions and feedback. As courses grow, documents become large, concurrent updates conflict, reporting is slow, and a search index occasionally displays content from the wrong tenant. Notifications are also duplicated when workers retry after timeouts.

Analysis

Enrollment, assessment results, and grading contain strong integrity requirements and require reporting across many records. They are therefore better represented relationally. Course content has variable structure and may be stored as documents, provided large files and unbounded submission collections are separated. Sessions and short-lived invitation tokens suit a key-value store. Search should be treated as a derived index rather than the source of truth.

The most serious risk is not merely performance but isolation: every query, cache key, search document, and event must carry an organization identifier. The notification issue demonstrates that at-least-once delivery requires idempotent processing.

Approach and solution

The team creates relational tables for organizations, users, courses, enrollments, assessments, submissions, and grades. Foreign keys and unique constraints enforce relationships such as one enrollment per user-course pair. Submission files are stored in object storage, while metadata remains relational. Flexible lesson content is stored as versioned documents linked to a course.

A cache-aside layer stores public course summaries using keys containing organization and course identifiers. Private assessment data is not placed in a shared cache without equivalent authorization controls. Search documents include tenant identifiers and are queried with mandatory tenant filters. An outbox table records course and content changes in the same transaction as the source update; a worker publishes events and updates search. Consumers use a unique event identifier to make processing idempotent.

The migration proceeds through expand-and-contract stages. New relational tables are introduced, historical data is copied in batches, counts and checksums are compared, and reads are gradually switched. During migration, the old and new paths are monitored in parallel.

Outcome

Reporting becomes predictable, document contention is reduced, and large submissions no longer enlarge course records. Search may still lag briefly, but its lag is measurable and acceptable. Duplicate notifications are eliminated through idempotency records. Tenant-aware constraints and query policies reduce the risk of cross-organization disclosure.

Learning points

The case demonstrates that database selection follows domain boundaries and access patterns. Polyglot persistence can be effective when ownership and recovery are explicit. Eventual consistency is acceptable only when users understand it and the system provides reconciliation. Security boundaries must be implemented consistently across primary stores, caches, indexes, and asynchronous workers.

11. Contemporary Developments and Critical Evaluation

Managed database services increasingly provide automated backups, scaling, replicas, encryption, and observability. Serverless and distributed SQL systems offer elastic operation, but may impose limits on transactions, connection patterns, or geographic consistency. Globally distributed systems require explicit reasoning about latency, conflict resolution, and jurisdictional data placement.

Vector search and embedding-based retrieval are increasingly used for semantic discovery and retrieval-augmented AI systems. They should be integrated with conventional authorization and source-of-truth controls. A vector index can improve similarity retrieval but does not guarantee factual accuracy, freshness, or permission correctness. Sensitive data used to create embeddings may also create privacy and deletion obligations.

AI-assisted coding can generate schemas, queries, migrations, and data transformations, but generated artifacts require human review, tests, security analysis, and production-like validation. An AI system may produce syntactically valid SQL that is inefficient, unsafe, or semantically wrong. Provenance, access control, and protection of confidential data must be considered when using AI tools with database content.

The central professional principle is evidence-based design. Benchmark representative workloads, inspect execution plans, test failure recovery, validate migration behavior, and document assumptions. No single data model or consistency strategy is universally superior.

Best-Practice Checklist

• Model domain invariants explicitly.
• Select storage according to workload and aggregate boundaries.
• Use database constraints for critical integrity rules.
• Keep transactions short and define isolation deliberately.
• Make externally retried operations idempotent.
• Examine ORM-generated queries and avoid N+1 access.
• Use backward-compatible, observable migrations.
• Index measured access patterns rather than every column.
• Treat caches and search indexes as derived unless explicitly designed otherwise.
• Apply tenant isolation to every data path.
• Bound pools, timeouts, and retries.
• Test backup restoration and migration rollback procedures.
• Minimize personal data and protect secrets and sensitive logs.
• Monitor latency, errors, lag, capacity, and data quality.

Chapter Summary

Data management is a foundational concern in web engineering because application correctness, performance, security, and resilience depend on persistence decisions. Relational databases provide structured schemas, joins, constraints, and strong transactional capabilities. Document databases model aggregates flexibly, while key-value stores support direct, low-latency access for sessions, counters, and temporary state. Polyglot persistence can match different workloads but increases operational and consistency complexity.

Transactions require deliberate treatment of atomicity, isolation, durability, concurrency anomalies, retries, and cross-system workflows. ORMs and ODMs improve productivity but cannot replace knowledge of query plans, indexes, transaction boundaries, and database behavior. Safe schema evolution commonly uses expand-and-contract migration steps. Caching and search improve user experience when their staleness, invalidation, indexing lag, and failure behavior are understood.

Layered validation, least privilege, tenant-aware access, privacy controls, tested backups, bounded retries, and observability are essential professional practices. Resilient systems identify a source of truth, tolerate partial failure, and make asynchronous or eventual-consistency behavior explicit. Emerging technologies, including distributed databases and vector search, are valuable only when integrated with sound governance, security, and evidence-based evaluation.

Key Terms

Data model: A formal representation of data, relationships, constraints, and operations.

Relational database: A database that represents data as related tables governed by a relational model.

Primary key: An attribute or attribute set that uniquely identifies a row.

Foreign key: A constraint referencing a key in another table.

Normalization: Structuring data to reduce redundancy and update anomalies.

Denormalization: Deliberate duplication or precomputation to support performance or domain requirements.

Document database: A database that stores self-contained, semi-structured records.

Key-value store: A store that retrieves values using unique keys.

Polyglot persistence: Use of multiple storage technologies within one system.

Transaction: A logical unit of work with defined completion and failure behavior.

ACID: Atomicity, consistency, isolation, and durability properties of transactions.

Isolation level: A database-defined guarantee concerning observations during concurrent transactions.

ORM: Object-relational mapping technology connecting application objects with relational data.

ODM: Object-document mapping technology connecting application objects with documents.

Migration: A controlled structural or data change to a persistence system.

Index: An auxiliary structure that accelerates selected data access paths.

Cache-aside: A caching pattern in which the application loads and populates cache entries on misses.

Idempotency: The property that repeating an operation produces the same intended effect as one execution.

Outbox pattern: A method that records business changes and publishable events in one local transaction.

Eventual consistency: A model in which replicas or derived views converge after updates rather than immediately.

Review Questions

Short Answer Questions

1. What distinguishes a document database from a relational database?

2. Define atomicity and durability.

3. Why can excessive indexes harm write performance?

4. What is the purpose of an idempotency key?

5. State two risks associated with ORM use.

Long Answer Questions

1. Compare relational, document, and key-value models, including suitable web application workloads for each.

2. Explain isolation levels and describe dirty reads, non-repeatable reads, phantom reads, and lost updates.

3. Describe an expand-and-contract migration and explain why it supports backward-compatible deployment.

4. Evaluate cache-aside caching, including invalidation, stampedes, staleness, and failure behavior.

5. Explain how validation, authorization, encryption, retention, and auditing contribute to responsible data governance.

Analytical / Application Questions

1. Design a persistence architecture for a multi-tenant online marketplace. Justify the choice of stores for orders, catalog data, sessions, and search, and identify consistency boundaries.

2. A payment request may be retried after a network timeout. Design an idempotent workflow and explain how database constraints, an outbox, and reconciliation would work together.

3. A production migration must split a large customer address field into structured components without downtime. Propose the migration stages, validation checks, rollback considerations, and monitoring metrics.

Multiple Choice Questions with Answers

Question 1

Which property ensures that either all operations in a transaction occur or none do?

A. Atomicity

B. Availability

C. Indexability

D. Partition tolerance

Correct Answer: A. Atomicity

Question 2

Which storage model is generally most suitable for short-lived sessions retrieved directly by identifier?

A. Key-value store

B. Graph database only

C. Search index

D. Normalized reporting warehouse

Correct Answer: A. Key-value store

Question 3

What is a principal risk of embedding an unbounded collection inside a document?

A. The document may grow excessively and suffer contention

B. The database cannot store any scalar values

C. All queries automatically become serializable

D. Foreign keys are created automatically

Correct Answer: A. The document may grow excessively and suffer contention

Question 4

What does the outbox pattern primarily help achieve?

A. Reliable publication of events associated with a local transaction

B. Automatic elimination of all duplicate messages

C. Immediate global consistency across databases

D. Removal of the need for backups

Correct Answer: A. Reliable publication of events associated with a local transaction

Question 5

Which migration sequence is designed for backward-compatible deployment?

A. Expand, migrate or dual-write, switch reads, then contract

B. Delete the old schema before deploying new code

C. Stop all services permanently during every change

D. Change application and database formats simultaneously without compatibility

Correct Answer: A. Expand, migrate or dual-write, switch reads, then contract

Question 6

Why can a cache-aside system return stale data?

A. The cached representation may remain after the source data changes

B. A cache always executes a serializable transaction

C. Indexes prevent cache invalidation

D. A key-value store cannot expire entries

Correct Answer: A. The cached representation may remain after the source data changes

Question 7

Which practice most directly prevents SQL injection?

A. Parameterized queries

B. Increasing database memory

C. Adding a full-text index

D. Using longer table names

Correct Answer: A. Parameterized queries

Question 8

What is an N+1 query problem?

A. One query retrieves a collection and an additional query runs for each item

B. A transaction contains exactly N plus one rows

C. A database has N replicas and one backup

D. A query uses one index too many by definition

Correct Answer: A. One query retrieves a collection and an additional query runs for each item

Question 9

Which statement about search indexes is generally correct?

A. They are often derived views and may be eventually consistent

B. They must always be the authoritative transactional store

C. They eliminate the need for authorization filters

D. They guarantee that every query is faster

Correct Answer: A. They are often derived views and may be eventually consistent

Question 10

What is the main purpose of a database foreign key?

A. To enforce a valid reference between related records

B. To encrypt a column automatically

C. To cache a query result

D. To determine HTTP retry timing

Correct Answer: A. To enforce a valid reference between related records