A useful database model represents what the business means by a customer, order, task, or reconciliation result. EidenTech can help design a new model or review an existing one before adding features or moving data. We connect the schema to real read and write patterns, permissions, and operational needs. That makes the design review about records and responsibilities rather than tables created independently by each screen.
How we approach your project
Model the meaning and ownership of each record
Determine which identifiers remain stable, which values change, and which history needs to be retained. A contact and an enquiry may be different records even when they share an email address. We review optional fields, status meanings, tenant boundaries, and the system authoritative for imported information. The model should explain incomplete records and corrections rather than assume every import arrives clean and every relationship is permanent.
Protect the rules that must remain true
Agree where constraints, uniqueness rules, and transactions should prevent invalid state. Application validation improves feedback, while database rules can provide an additional boundary when several processes write records. We identify the consequences of concurrent updates, deleted relationships, and repeated submissions. Some history may need a separate event or audit representation rather than overwriting the current row. Access requirements can influence schema design as well as application permissions. Where row-level access controls are appropriate, their behaviour must be reviewed with the intended connection roles and query paths.
Design for the queries that matter
A schema should support the way users find and act on records. Identify important list views, filters, reports, and batch operations before selecting indexes or adding derived values. We inspect representative data volumes and query behaviour rather than promise performance from an empty database. Indexes can help some reads while adding write and maintenance costs. Large exports, pagination, and aggregation may need different handling from a detail view. The design should also state whether a report is current, delayed, or calculated from a particular snapshot.
Move and evolve data without losing its meaning
Schema changes and imported datasets need a controlled process. Review mapping, duplicate handling, required relationships, and rows that cannot be accepted. A migration should account for the application versions reading and writing during the change, not just whether a SQL statement executes. We define validation evidence such as record counts and representative relationships, with an owner for exceptions. Destructive changes need appropriate backups and an agreed recovery approach. An import preview or reconciliation report can help a team resolve ambiguity instead of silently converting it into apparently valid records.
Make retention and restoration operational decisions
Clarify who can access, export, retain, and delete information, and which records are needed for the business workflow. Data minimisation and retention requirements influence backups as well as the main database. We document restoration responsibilities and the checks needed to establish that a recovered database works with the application. A configured backup is not the same as a tested recovery path. Handover covers schema documentation, migrations, relevant query assumptions, and maintenance ownership so future changes can preserve integrity and avoid rediscovering undocumented field meanings.
What we can deliver
We agree the requirements and responsibilities before development begins. Your project scope can include:
- A data model and field definitions connected to the business workflow and record ownership.
- An agreed schema with relationships, constraints, and appropriate access boundaries.
- Query and index planning for the principal application views and reports.
- Data migration or import checks, exception handling, and recovery assumptions.
- Schema, retention, and restoration guidance for the team maintaining the application.
Technology choices for your requirements
The stack follows your integrations, operating model, and maintenance needs. These are options to review during discovery, rather than a fixed stack promised for every project.
- PostgreSQL and relational schema or migration tooling where appropriate
- Database constraints, transactions, indexes, and row-level controls suited to the access model
- Validated CSV or Excel imports, backups, and query analysis tools
Planning questions, answered
Can you review a database without rebuilding the application?
Yes. We can scope a review of schema meaning, data quality, access, and important queries. Some improvements may fit the existing application, while others need coordinated interface or API changes that should be identified before implementation.
Can we import existing spreadsheets?
Yes. We agree column mapping, formats, required relationships, duplicate matching, and exception handling first. A test import should show which rows were accepted and which require review, rather than silently discarding ambiguous information.
Does every application need a relational database?
The choice follows relationships, write consistency, access patterns, and operations. We review those requirements before selecting persistence. Existing systems and integration constraints also matter; a database technology should not be chosen only because another project used it.
Can database design include permissions and backups?
Yes. Access roles, tenant boundaries, retention, and restoration requirements belong in the design brief. The final controls and procedures depend on the application and hosting environment, with recovery checks agreed as part of the relevant scope.
Tell us what needs to work better.
Share your idea, existing workflow, and the outcome you need. We will help shape a practical starting point.
Start a project conversation ↗Read our website, chatbot, and product planning guides →