3 ms·

No, you shouldn't use a code first, or a database first design. The article explains the problems with the code-first approach very well, but there are just as

No, you shouldn't use a code first, or a database first design. The article explains the problems with the code-first approach very well, but there are just as many problems with the database-first approach: - There is never just one database. There will be your production database, a staging database, one or more testing databases, local development databases, etc. This makes the database useless as a single source of truth. - When you write code against your development database, there's no guarantee that it will be the same as the production database, and you shouldn't be able to connect to your production database while developing locally to verify that. Usually you want to deploy identical build artefacts to staging and production, so there's a danger that your staging database gets out of sync with production (eg. after an issue was caught and improperly rolled back on staging) and then you deploy your fully tested code from staging to production and your entire system breaks down. - When you need to restore a backup of your database, you need to somehow find a compatible version of the code to deploy as well. My recommendation is to use your migration scripts as your source of truth. Each service should access separate schemas within the database, or at the very least separate tables. If you really need multiple services to share tables then those services should be versioned and deployed as one. The database should have a table which stores a list of the migrations which have been applied, and you should use a migration tool such that when you deploy, outstanding migrations are applied as required. If you want something easier to read than the history of migration scripts, then you should keep an up-to-date schema as well next to your code, and verify as part of CI that running all the migrations results in that exact schema.

acutesoftware 8y ago
In the very early stages of development it doesn't really matter how you build your database schema, but spending some time getting the data model as clean as possible it pretty important. Agree that scripting is important once data moves to production - once that happens, the database in Prod is master and the deploy script controls not only the code being pushed but also any database changes. If you are lucky and have planned the initial layout, you'll never need to remove columns or tables, so a single deploy script can do it all (update database schema and push new app)
andreimackenzie 8y ago
It can help to establish rules such as "new DB migrations must always be compatible with old code" aka "migrations first". This gets everyone into the mindset that a db+code change must be carefully staged in a way that both (new DB, old code) and not just (new DB, new code) are tested. If the migration goes wrong due to different data in prod, it's easier to roll that back before new code is deployed.
- hinkley 8y ago
  Anything faster than what you’re suggesting here is trying to rush the process. Create the data before it’s needed, clean up old records, verify the quality, make it required. And only then do you use it.

acutesoftware 8y ago

In the very early stages of development it doesn't really matter how you build your database schema, but spending some time getting the data model as clean as possible it pretty important. Agree that scripting is important once data moves to production - once that happens, the database in Prod is master and the deploy script controls not only the code being pushed but also any database changes. If you are lucky and have planned the initial layout, you'll never need to remove columns or tables, so a single deploy script can do it all (update database schema and push new app)

andreimackenzie 8y ago

It can help to establish rules such as "new DB migrations must always be compatible with old code" aka "migrations first". This gets everyone into the mindset that a db+code change must be carefully staged in a way that both (new DB, old code) and not just (new DB, new code) are tested. If the migration goes wrong due to different data in prod, it's easier to roll that back before new code is deployed.

hinkley 8y ago
Anything faster than what you’re suggesting here is trying to rush the process. Create the data before it’s needed, clean up old records, verify the quality, make it required. And only then do you use it.