Jan Mikoláš
Designing and changing a schema
Keeping data consistent
- Entities and their relationships
- Constraints and referential integrity
- Transactions for related changes
- Traceable migrations
Back to skills
Experience
Databases and data design
I do not see a database as an application’s storage alone. A well-designed schema, data integrity, and predictable queries are the foundation of a stable system.
Data design is part of application design.
When working with relational databases, I start with the relationships between data, explicit constraints, and transactions. Only then come the ORM, repository, or a particular query — tools should support a sound model, not replace it.
Today, I work with PostgreSQL most often. I previously used MySQL and MariaDB, which helps me recognise practical platform differences and choose an approach based on application needs, data volume, and operational requirements.
Not familiar with a term? Read a concise explanation in the glossary.
What I address when working with data
From a sound model to performance in production.
-
Data model
Relationships and constraints in the database
I consider what the database itself must guarantee: uniqueness, required relationships, referential integrity, and domain-important constraints. This reduces the room for inconsistent data. -
Safe change
Transactions and migrations
Related data changes need to happen together or not at all. I evolve the schema through migrations so a change is traceable, repeatable, and as safe as possible for the deployed application. -
Performance
Indexes, queries, and N+1
When a system slows down, I do not guess. I look at the query shape, required indexes, number of records loaded, and whether an ORM is producing an N+1 problem. The result guides changes to the model, loading strategy, or a specific SQL query. -
Data volume
Imports and batch processing
For larger imports, it is important not to load everything into memory, process data in batches, define transaction boundaries sensibly, and be able to resume from a safe state.
A practical approach
An ORM is a tool; database design remains a decision.
I use Doctrine for everyday work with entities and consistent model mapping. If a particular query needs more precise control, aggregation, or better performance, directly written SQL is the appropriate and readable choice.
I do not try to hide the database behind an abstraction at all costs. Data correctness, clarity, and appropriate performance matter more.
Reading and processing data
Keeping queries effective
- Doctrine for the common model
- Query profiles and needed indexes
- Focused SQL for specific cases
- Pagination and batches for large volumes
Databases and tools I use
From relational design to application work
- PostgreSQL
- Doctrine
- Redis
- SQLite
- MySQL
- MariaDB
- DataGrip
- Migrations
Need to design or speed up your data work?
I can help from schema design through migrations to investigating a specific issue in queries or imports.