Reply to: Accidentally nuked production database

[fool]

I don't believe this story either.

There is no way that a junior dev on their first day can nuke a production database.

And if they could, the dev wouldn't be fired - someone more senior would for making it possible.

I believe it because I did the same thing, as posted in the other thread. Literally on my first day too. I wasn't fired though.

The owner threw a bit of a strop, but everyone else asked me how I managed it then told me it was an easy thing to do.

[BrilloPad]

That's where I do all my testing, cause it takes the DBAs too long to copy down to Dev/CRP/QA

For the last year I was working at a place in Bangor with only one environment. Amazingly I did not make a single screw up. Either I am getting old or I am not working fast enough.

[MrMarkyMark]

That's where I do all my testing, cause it takes the DBAs too long to copy down to Dev/CRP/QA

Ours replicates fairly quickly, after a few hours.

The main issue is that the offshore team have trouble getting the latest months data I request.
This is even after confirming that a certain Month End will need to be in there 4 times

[WTFH]

So you never have had the pleasure of a place with just the one environment (prod)

That's where I do all my testing, cause it takes the DBAs too long to copy down to Dev/CRP/QA

[BrilloPad]

Somebody should start a "What is the Biggest IT Cockup You've Ever Made?" thread.

Don't be silly.

[MrMarkyMark]

I've not made one.

I was once told I had to touch production systems but managed to get out of it.

So you never have had the pleasure of a place with just the one environment (prod)

[SueEllen]

Somebody should start a "What is the Biggest IT Cockup You've Ever Made?" thread.

I've not made one.

I was once told I had to touch production systems but managed to get out of it.

[xoggoth]

Somebody should start a "What is the Biggest IT Cockup You've Ever Made?" thread.

[woohoo]

DBAs are the custodians of the data, Devs are the chaos monkeys that need to be tamed.

DBAs are failed devs, they then guard the database so the devs can't see how tulip they are.

Only joking again, some of them are failed testers or even worse failed project managers.

Ok need to get back to my work, this access database won't design itself.

[BigRed]

DBAs are the custodians of the data, Devs are the chaos monkeys that need to be tamed.

[MrMarkyMark]

Which is not necessarily that slow

[GJABS]

Literally became like a Ferrari dragging a caravan after 6 months.

Which is not necessarily that slow

Edit: Above link doesn't work properly. Click this instead:
https://www.youtube.com/watch?v=h5GivB7LHXo

[GJABS]

ooooohhh you dba's get so protective, god help you if a clever dev ends up doing a bit of database work and your plate juggling is found out.

I'm sure you're right - in some ways the DBA is the "drummer" of the IT world. As in a bit thick and lacking in imagination.
But as gatekeepers, they can be excellent.

[MrMarkyMark]

I don't know about where you work but the major issue I have seen around letting Dev's be DBA is that the ancient and mystic trade of schema design and normalisation seems to go straight out the window. If you screw up a DB schema and then compound it with bad table placement on the disks there is absolutely nothing you can do to recover the lost wasted space and application performance.

We had Mongo come to see us at one of my previous clients and one of the things they wanted us to do was create DB shards on three volumes on a raid 10 SAN.

Or, back in the day, you buy a very expensive Netezza box for your DW.

Lovely machine at the time.

You then decide you can just dump all sorts of tulipe code on it, against others and my advice.
No dimensional schema modelling required.
'cos its quick, right?

Literally became like a Ferrari dragging a caravan after 6 months.

[bobspud]

I'm only messin - I recognise the need for processes, I just don't like the distinction between DBA's and Devs. I think a developer needs to have an excellent and practical understanding of databases.

I don't know about where you work but the major issue I have seen around letting Dev's be DBA is that the ancient and mystic trade of schema design and normalisation seems to go straight out the window. If you screw up a DB schema and then compound it with bad table placement on the disks there is absolutely nothing you can do to recover the lost wasted space and application performance.

We had Mongo come to see us at one of my previous clients and one of the things they wanted us to do was create DB shards on three volumes on a raid 10 SAN.