Database design structures application data so it can be stored, queried, related, and protected against integrity problems. Relational databases support this work through tables, primary keys, foreign keys, constraints, and referential integrity. section 5.12
A practical database-design workflow for an ACH application includes:
- Start with the functionality users need, such as uploading ACH files, then identify the records and relationships required to support it. section 5.11
- Create tables incrementally, update the parser, and verify each change with unit tests in short feedback cycles. section 5.4
- Use research spikes or enabler stories to test uncertain design and implementation approaches before committing to a larger build. section 5.11
- Revisit the structure as requirements become clearer; testing, refactoring, and changed scope can reveal missing relationships or tables. section 5.12
ACH dashboard database
An ACH dashboard can use a PostgreSQL database to store parsed ACH data instead of relying on flat files. Designing the ach_files table and its foreign keys early would provide a stronger foundation for APIs, parsing, querying, and the MVP. Each additional record type can then be added through a repeatable cycle of table creation, parser updates, and test verification. section 5.11 section 7.2 section 5.4
Figure 7.1 The pieces and parts fed into the MVP
Use the system overview to see how database design connects the ACH parser, APIs, user interface, testing, and security work required for the MVP. section 7.2
