A citizen-feedback portal stores evolving JSON documents whose fields change as new survey types appear. Which database pattern fits better than a rigid relational schema?
Select an answer to reveal the explanation.
Short Explanation
Think of citizen feedback like sticky notes that keep gaining new corners — rigid spreadsheet columns fight you every week. Document stores shrug and keep the JSON as it grows. You are picking flexibility for semi-structured data, not forcing a migration circus for every survey tweak.
Full Explanation
Non-relational document stores are suited to flexible, semi-structured JSON documents whose fields evolve without forcing a rigid table migration for every change. A citizen-feedback portal that stores evolving survey JSON as new survey types appear therefore fits a document database better than a highly normalized relational schema that must migrate for each new field. A highly normalized relational schema that requires a migration for every new field creates change friction exactly where survey agility and rapid civic engagement features are needed. Tape archive media restored offline once per quarter cannot serve an interactive feedback portal with acceptable citizen response times. A bare-metal SAN LUN formatted only for block-level database filesystems is an infrastructure detail, not a document data-model choice that solves schema flexibility. Exam caveat: document stores trade some relational join and constraint patterns for schema flexibility—do not assume they replace payroll-style ACID relational needs when foreign keys and strict transactions dominate. Operational check: define document collections for survey responses, validate required core fields in application logic, version survey schemas in metadata, back up the document store on a tested schedule, encrypt PII, and load-test the query patterns analysts use when reviewing citizen feedback.