A budget office needs complex multi-table joins across funds, vendors, and appropriations for mandatory financial reports. Why is a typical NoSQL document or KV store often a poor primary fit?
Select an answer to reveal the explanation.
Short Explanation
Big multi-table budget joins are relational comfort food. Many NoSQL models make you contort or pre-bake those joins. Keep the heavy financial reporting where joins are natural.
Full Explanation
Relational databases excel at complex joins across normalized financial entities such as funds, vendors, and appropriations. Many NoSQL models discourage or poorly support ad hoc multi-table join-heavy reporting. Forcing that workload into document or key-value primaries often yields awkward denormalization or incomplete reports. Recognizing NoSQL anti-fits is as important as recognizing good fits.