Support/Legal & Policies/How databases are designed
Legal & Policies

HOW DATABASES ARE DESIGNED

2,311 views
databaseapp

We design application databases by translating operational workflows and query demands into structured schemas, managed entirely by our Technology department from initial entity modeling to production migrations.

Database design at Xylora Studios translates your product workflows, read/write requirements, and reporting needs into a resilient data structure. Every schema is planned and verified by our Technology department before application development begins.

The Design Sequence

Database engineering follows four distinct operational stages to prevent schema drift, data corruption, and query bottlenecks.

1. Domain and Entity Mapping: We audit your business workflows to establish core entities (such as accounts, transactions, assets, or audit logs) and the relationships between them (one-to-one, one-to-many, or many-to-many). 2. Engine and Paradigm Selection: Our Technology department selects the storage engine based on your data shape and access profile. Relational engines (typically PostgreSQL) are chosen for structured, transactional systems requiring strict ACID compliance; document or key-value stores are reserved for high-throughput, semi-structured data. 3. Schema Definition and Normalisation: We write explicit schemas, enforce strong data typing, configure primary and foreign keys, apply constraint checks, and define indexes according to anticipated query patterns. 4. Migration Architecture and Staging: We build repeatable, version-controlled migration scripts. The complete schema is provisioned in an isolated staging environment and tested against synthetic load before connecting to live services.

What You Must Supply

To construct an accurate data model without structural revisions mid-build, you must provide the following before technical planning concludes:

* Workflow Specifications: Complete user journeys and transactional workflows, detailing how records are created, updated, archived, and deleted. * Legacy Data Samples: Clean exports (CSV, JSON, or SQL dumps) of any existing data you intend to migrate, including current volume metrics. * Access and Permission Rules: Role definitions specifying which system actors may read or modify specific data fields. * Compliance Constraints: Retention obligations, geographic storage requirements, or legal constraints governing your sector.

If you have a referral discount (typically 10-30%, confirmed in writing on your quote), ensure your referrer is verified via the ambassador programme prior to sign-off.

Department Responsibilities and Timings

The Technology department handles entity modeling, query performance tuning, index maintenance, and migration scripting. Operations & Client Services manages schedule alignment, sign-offs, and communication.

Our working hours are Monday to Thursday, 09:00-17:00 GMT. Messages sent via the Ask Xylo chat receive an initial response within our 24-hour target. Where database design forms part of a bespoke software build, technical specifications and estimates are issued within 48 hours of receiving a complete brief. Fixed-scope database implementations included in standard packages follow the pricing and milestones detailed on the packages page.

Deposits are non-refundable once your production slot is held. Before work begins, sums not yet earned are refunded pro rata; after work begins, completed work and booked time are charged. Defects are fixed free of charge within the acceptance window. The full terms are on the Refund Policy page of the main site. Schema work begins only once the initial deposit clears.

Failure Cases and Preventative Measures

Schema design issues are expensive to resolve once production applications are live. We actively prevent the following pitfalls:

* Scope Changes Mid-Development: Introducing new business rules or relationships late in the project can invalidate existing schemas. Structural additions requested after schema approval require formal change requests and revised delivery dates. * Unchecked Legacy Imports: Importing dirty historical records without upfront cleaning causes constraint failures. We require clean, validated data files before running ingestion scripts. * Over-indexing or Missing Indexes: Every index speeds up reads but incurs a performance cost on writes. We index foreign keys and high-frequency filter columns deliberately, profiling queries under simulated concurrency. * Imprecise Data Types: Storing currency as standard floating-point numbers or omitting timezone offsets on timestamps causes cumulative calculation errors. We enforce discrete integer or decimal fields for monetary values and UTC timestamps across all systems.

Database Readiness Checklist

Before we finalise your database specification, ensure you have completed the following:

* Documented all core entities, their properties, and their real-world relationships. * Provided an anonymised sample of historical data for ingestion testing. * Defined user roles and data access permissions. * Confirmed statutory data retention and regional hosting requirements. * Reviewed and approved the entity relationship diagram (ERD) issued by our Technology department via Ask Xylo.

Was this helpful?

Tell us honestly. It is read by the people who write these pages.

If this didn't answer your question, ask Xylo.

Back to Legal & Policies