People screw up. I think it is better to make sure that you are always working over a safety net.
Safety nets for developers include automated tests, rolling out upgrades to a 'pre-production' clone of your real server before doing the real upgrade, and keeping your code in version control so you can reverse mistakes quickly.
For database work, not working on the production database, lots of backups, and using transactions all work for me, but some databases support Point In Time recovery if you have it turned on.
But what works best is doing code reviews, including reviews of SQL that is going to be executed against the database. Two heads are better than one.
Thank you. I'm going to screw up again at some point just hoping to get best practices for preventing it. I should have mentioned I work for a tiny startup that doesn't have someone competent to review the SQL.
I think that even if the other developers are not familiar with SQL specifically, you can show them the query you plan on running.
I׳ve found that the fact that you need to explain something to someone makes you double check everything, and reduces the chances of screwing up.
Even if they׳re not familiar with SQL, they can still easily understand the logic behind the query.
Comments
People screw up. I think it is better to make sure that you are always working over a safety net.
Safety nets for developers include automated tests, rolling out upgrades to a 'pre-production' clone of your real server before doing the real upgrade, and keeping your code in version control so you can reverse mistakes quickly.
For database work, not working on the production database, lots of backups, and using transactions all work for me, but some databases support Point In Time recovery if you have it turned on.
But what works best is doing code reviews, including reviews of SQL that is going to be executed against the database. Two heads are better than one.
Thank you. I'm going to screw up again at some point just hoping to get best practices for preventing it. I should have mentioned I work for a tiny startup that doesn't have someone competent to review the SQL.
I think that even if the other developers are not familiar with SQL specifically, you can show them the query you plan on running.
I׳ve found that the fact that you need to explain something to someone makes you double check everything, and reduces the chances of screwing up. Even if they׳re not familiar with SQL, they can still easily understand the logic behind the query.
Yeah, that is a problem. Could you train up one of the cofounders slowly on the basics? I mean, someone needs to fix the database if you are ill...
Mistakes are kind of human nature though. I think a lot of 'best practice' is about trying to spot them before they cause a big problem.