- Data models change and evolve with your application.
- There’s plenty of tools that keep track of database schemas and automatically generate scripts to upgrade or downgrade them.
- It’s common for developers to run a migration at the start of their app before running app code.
- Our author explains two common problems with this approach.
- Modern day production deployments and horizontal scaling can get you into a race condition.
- You start assuming that new code will only ever run with the new schema.
- You can decouple migrations from code changes by disabling parallelism during this time.
- Make it a separate command or lock the database during the upgrade.
- We can easily implement locking ourselves in any language.
- Use Redis locks if you’re ok with something external to the DB.
- Use the DB itself by writing to an extra table to say that you’re upgrading it.
- Plan your deployment appropriately so you can run old code with new by making migrations additive in the short term.
- Using a script at startup that optionally performs the migration based on an environment variable integrates wel with Docker and cloud services.
- Upgrades of both code and data should be part of your testing BEFORE releasing to production.
- It’s up to us to learn how to apply design patterns and industry trends to our projects.
- What’s an Object Relational Mapper (ORM)?
- Why do I want to use one?
- Unexpected quirks of using ORMs. What are the tradeoffs?
- What about scalability?
I’ve been using some form of a database throughout the entirety of my career. Sometimes single-file databases, sometimes full servers. Sometimes testing them, sometimes designing them, but a lot of times I was optimizing them. Even when learning programming with my dad, most of the apps I built were about storing and managing some type of data.
With all those years of experience, I definitely understand enough to know that I’m by no means an expert at any of it. There are several (an understatement) mechanisms by which folks make the best use of their database servers, almost all of them are tradeoffs in memory usage, space, look-up times, results retrieval, backup mechanisms, etc.
As expected, each database mechanism has their own quirks and optimizations, but the common theme is the language which you use to retrieve information: Structured Query Language (SQL). Different database engines implement different extensions to this language, some of which add powerful functionality, some of which just add confusion. But in general, SQL has been very successful in standardization across the industry.
This next chapter in the Practicality Beats Purity series covers the tradeoffs when using direct SQL queries to a database vs programming language abstractions that do it for you, like ORMs.Continue reading