County payroll requires ACID transactions, normalized employee and deduction tables, and strict foreign-key relationships. Which database approach best fits?
Select an answer to reveal the explanation.
Short Explanation
Payroll is like a careful ledger where every line has to balance and every employee row ties cleanly to deductions. Relational databases give you that strict table structure, ACID safety, and foreign keys. Caches, graphs-for-fun, and raw CSV dumps are the wrong tool for paycheck accuracy.
Full Explanation
Relational databases are designed for structured transactional data with schemas, normalized tables, and integrity constraints such as foreign keys, supporting ACID transactions required by payroll. County payroll that needs ACID behavior, employee and deduction relationships, and strict referential integrity therefore fits a relational approach. An in-memory key-value cache with no durable schema or relationships may accelerate reads but is not the system of record for durable payroll transactions. A graph-only store optimized for social-style friend links does not match normalized payroll tables and deduction constraints. Object storage buckets holding flat CSV files without a query engine lack transactional ACID guarantees and relational constraint enforcement. Exam caveat: choose the data model from workload characteristics—ACID + relationships point to relational—before debating managed versus self-managed deployment. Operational check: model employees, deductions, and pay events with constraints, run payroll reconciliation tests under concurrent updates, enable point-in-time recovery, encrypt data at rest and in transit, and restrict DBA and application roles to least privilege.