Steph's avatar
Level 1

Very first migration

Hello everyone, one simple question here: I am wondering, between the two bellow options, what is the best for creating a DB on a project first deploy:

  1. creates a DUMP of the fresh, original database, and manually import it at the new environment deploy
  2. create a "first migration" file which will do the job at the very first service start

Here what I personnally think of those two options (taking into account that both option may be versionned, so this very point is out of the equation):

  1. PRO: trivial to create; easy readable for whom can read SQL; CONS: outsite of the Laravel world, and easily breakable by manual changes
  2. PRO: inside Laravel microcosm, this with all the corresponding Eloquent checks; CONS: long to create; harder to read/maintain than a simple SQL file

In other words, on my own points view only, I can't decide. Do you see any other PRO/CONS which would permit me to decide which one to chose ?

Thank you very much in advance.

0 likes
2 replies
s4muel's avatar
s4muel
Best Answer
Level 50

is it a brand new project? if so, there should be (well it doesn't have to be, but that is the purpose of it) a migration file for every database table. so as you create and modify database tables in the project's lifecycle, everything is tracked in migration file(s). so after first deploy to a new environment, every migration is ran and the DB structure is created step by step.

if it is a ongoing project with already existing database, the easiest way really is just to dump the database (your first option) and use it in the first migration, but i personally prefer (have done both in the past) to just write a migration for all existing tables. either manually or with a help from external tool. not sure RN, but i think i used this package: https://github.com/kitloong/laravel-migrations-generator which basically connects to a DB and writes migrations for you. i had to tweak it a bit, but it was great help.

i would choose that way. the syntax is sure different from SQL, but i think a developer which can read SQL would have no problem reading the migration file and know what is what without any trouble.

this was about the structure, there is a big question about data, but i would rather not dig into that. if not needed, because it complicates things a bit.

Steph's avatar
Level 1

Well, in this very case, I think I'll keep the original data inside the DUMP/first migration file (depending on what will be chosen) as they are not supposed to change (and even if, in design I agree, format and data shouldn't be mixed together). But the fact that tools exist to transform an SQL DUMP into Eloquent migration changes a lot of things (I was not aware of it, thank you for that piece of info !!!) :) I'll give that tool of yours a try, and if it works fine with our actual database, I think I'll be tempted with the second option, indeed ;)

1 like

Please or to participate in this conversation.