3 ms·
"BEFORE a developer accidentally drops a table?" Ideally, you don't want developer(s) to have access to destruct data especially things like DROP. Now, a lot o
by codegeek 3y ago
"BEFORE a developer accidentally drops a table?"
Ideally, you don't want developer(s) to have access to destruct data especially things like DROP. Now, a lot of small businesses may not have the resource to have separate DBAs etc but the rule still applies.
This is more a control problem than a code problem. Having said that, you could write triggers to stop DELETE or DROPs from happening if you cannot control the access.
- kvaranasi_ 3y agoInteresting idea to use Triggers.
- tracker1 3y agoI've made it a personal rule for a while now, that I generally won't touch production once it is "online" ... I'll work initial setup, but after that, I'm happy to be on a screen sharing session walking someone else through what to do, so I don't have access and cannot touch it directly. Usually in favor of a CI/CD pipeline that will do regular releases. This at least lowers risk, but doesn't strictly prevent a DROP in a db/migration script. All the same, I don't touch prod servers, and especially don't touch client prod servers.