[hackoder]

I was in a situation very similar to yours. Also a game dev company, also lots of user data etc etc. We did have test/backup databases for testing, but some data was just on live and there was no way for me to build those reports other than to query the live database when the load was lower.

In any case, I did a few things to make sure I never ended up destroying any data. Creating temporary tables and then manipulating those.. reading over my scripts for hours.. dumping table backups before executing any scripts.. not executing scripts in the middle/end of the day, only mornings when I was fresh etc etc.

I didn't mess up, but I remember how incredibly nerve wracking that was, and I can relate to the massive amount of responsibility it places on a "junior" programmer. It just should never be done. Like others have said, you should never have been in that position. Yes, it was your fault, but this kind of responsibility should never have been placed on you (or anyone, really). Backing up all critical data (what kind of company doesn't backup its users table?! What if there had been hard disk corruption?), and being able to restore in minimum time should have been dealt with by someone above your pay grade.

[arethuza]

Out of interest, why not create a database user account that is read only and use that?

[hackoder]

It was a bunch of different tasks. For some, we did use a read only account. Other tasks (updating top 10 scores, updating the users table with their geo-ip based location etc) required write access.

Just to add some more thoughts based on other comments.. yes a lot of companies do stuff like this, particularly startups. The upside in these situations is that you end up learning things extremely quickly which wouldn't be possible in a more controlled environment. However not having backup and restore working is just ridiculous and I keep shaking my head at how they blamed the OP for this mistake. Unbelievable.

[petriw]

Just remember to always verify it's still read only.

Or a coworker will find the login in your scripts, repurpose it, then notice they need more rights and "fix" the account for you.

[MBCook]

Plus read-only isn't a guarantee. You can't write data, but you can run a bad select or join that ends up effectively locking the database.

SELECT * FROM my_200_GB_table will always be there.

[michaelt]

Why should a select or join lock a database? Surely no database lets one query starve another of IO or CPU?

[mst]

I like to suffix such account names with _readonly.

[arethuza]

"find the login in your scripts"

It's actually quite nice using a database server that doesn't require explicit credentials to be used.