Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
and this is why i just use adminer.org and drop it on any project i'm working on, connect, make changes, save, close browser window, and delete the file when done.
easy peasy, none of this manual writing basic queries to add/remove stuff.
Doing it manually is not sustainable in the long run. Having a schema migration tool during the deployment is a breath of fresh air.
It also helps to onboard others more quickly. Just run the migrations and maybe a seeder for initial data. Then you don't need to point new people to the production database to get the schema.
Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
hold on, if anyone's being onboarded, you should be able to create a backup to give them.
Is there still reason to write CREATION queries, not really.
Adminer is one file. They can literally copy it locally too you can then export from prod and let them import the file in one go.
There is ZERO reason to ever write CREATE queries anymore. Also, by not writing them you can never run them twice and override existing tables because someone forgot to add the "EXISTS" check on em.
I am not sure if I understand your point.
1) You should not write exists check because CI/CD will handle it. All seed and migration script can be handled there too
2) Do you want to copy prod database to local or dev env?
It’s not secure, you should not share prod data, it won’t work when database is 100+ GB.
Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
Continuous Integration and Continuous Deployment should not be the tools that CREATE your database or new tables. Those are one time events you do not need to add to recurring tools. That just adds more chances for something to go wrong and break your database.
Prod data depends on the site. As far as it being secure or not.
How many systems have you worked with? The majority of them have zero security, no one cares about it until they get sued. If there is sensitive data then you need dummy data for dev, but if it's a website with dynamic content you need to copy prod to dev pretty regularly to keep the two consistent for testing new additions in code.
Different systems need different things, there is no one stop solution for everything.
And none of that has anything to do with the initial database creation which again should not be added into recurring processes.
It is clear you don't understand how database migration tools work. In short you add queries, like the examples, to a file. And the database migration tool checks if the file is already executed or not.
An added benefit is that you can write a rollback query in the file as well, for when things go wrong during a deploy.
Do yourself a favor and learn more about the tools that help you improve your workflow.
Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
why?
Writing CREATE queries is absolutely not necessary anymore these days.
And when you have multiple devs, you mainly need an export/import process , or a batch script that can pull from prod into their local.
No one needs to write CREATE queries like these anymore, haven't had to for years.
Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
it depends on the project, there is no one size fits all solution for this.
Simple wordpress sites for example, you can easily have a bash script that a dev runs locally that connects to the dev database, exports it, imports it locally and runs a domain swap so the local urls work correctly.
Every framework/platform/system is going to be different depending on setup and structure.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
and this is why i just use adminer.org and drop it on any project i'm working on, connect, make changes, save, close browser window, and delete the file when done.
easy peasy, none of this manual writing basic queries to add/remove stuff.
Doing it manually is not sustainable in the long run. Having a schema migration tool during the deployment is a breath of fresh air.
It also helps to onboard others more quickly. Just run the migrations and maybe a seeder for initial data. Then you don't need to point new people to the production database to get the schema.
hold on, if anyone's being onboarded, you should be able to create a backup to give them.
Is there still reason to write CREATION queries, not really.
Adminer is one file. They can literally copy it locally too you can then export from prod and let them import the file in one go.
There is ZERO reason to ever write CREATE queries anymore. Also, by not writing them you can never run them twice and override existing tables because someone forgot to add the "EXISTS" check on em.
I am not sure if I understand your point.
1) You should not write exists check because CI/CD will handle it. All seed and migration script can be handled there too
2) Do you want to copy prod database to local or dev env?
It’s not secure, you should not share prod data, it won’t work when database is 100+ GB.
Continuous Integration and Continuous Deployment should not be the tools that CREATE your database or new tables. Those are one time events you do not need to add to recurring tools. That just adds more chances for something to go wrong and break your database.
Prod data depends on the site. As far as it being secure or not.
How many systems have you worked with? The majority of them have zero security, no one cares about it until they get sued. If there is sensitive data then you need dummy data for dev, but if it's a website with dynamic content you need to copy prod to dev pretty regularly to keep the two consistent for testing new additions in code.
Different systems need different things, there is no one stop solution for everything.
And none of that has anything to do with the initial database creation which again should not be added into recurring processes.
It is clear you don't understand how database migration tools work. In short you add queries, like the examples, to a file. And the database migration tool checks if the file is already executed or not.
An added benefit is that you can write a rollback query in the file as well, for when things go wrong during a deploy.
Do yourself a favor and learn more about the tools that help you improve your workflow.
Hello, Revavyr
"adminer.org" could work for small projects or small teams. But it becomes unreal when the team is 5+ engineers.
why?
Writing CREATE queries is absolutely not necessary anymore these days.
And when you have multiple devs, you mainly need an export/import process , or a batch script that can pull from prod into their local.
No one needs to write CREATE queries like these anymore, haven't had to for years.
Could you please describe this process? It will be interesting to see it
Thanks
it depends on the project, there is no one size fits all solution for this.
Simple wordpress sites for example, you can easily have a bash script that a dev runs locally that connects to the dev database, exports it, imports it locally and runs a domain swap so the local urls work correctly.
Every framework/platform/system is going to be different depending on setup and structure.