: Is it bad to develop against production data? I've always heard that it is bad practice to develop against production data and am currently in the process of moving to a Dev>Stage>Production

@Merenda212

If you have production data available, it is reasonable to use them for testing, but use a separate testing database with a copy of that data. Otherwise many things will work for your few "blabla" testing records but not for a real scenario.

And for developing on a live production data - remember the Murphy's laws "Anything that can go wrong will go wrong.", and it is so easy to make a small mistake with large bad consequences .

Vote Up Vote Down

@Nimeshi995

If you don't drive without a seatbelt, don't develop on production data. Just a safety issue.

Vote Up Vote Down

@RJPawlick198

You do NOT want to develop against production data on your production server. There are a couple of huge reason.


Development slows down your production box and creates vulnerabilities. What happens if you leave your computer unlocked and walk away?
If you make a mistake people that visit your site can see it.
If you do any kind of data update inside of a Transaction in your database and you don't commit it immediately or the transaction takes a while to finish you will put a lock on all of the tables involved and you could cause a timeout to occur.
Some database systems, specifically SQL Server will do table locks at times on SELECT statements alone! Which means you can unintentionally give people timeouts or error pages on your site.


I would never do development work on a live box if possible. Your best bet is to make a backup of the Database and pages and work with the copy and then push your updates. One tool that has helped me a ton is Msft's SyncToy.

Vote Up Vote Down

@Dunderdale272

If during development you are running SQL commands that include INSERT or UPDATE on existing database tables, you are running a risk to the extent that those database tables are mission critical.

Some places sync production data into the development database at some interval, say, once a week or at developer request so you have fresh data to develop with.

But if your production data is not at risk from what you're doing, for example, if you were simply developing a view of some data, usually it's not a big deal. Now, if you're running reports that do table scans, then you have the potential to lock up a table, then your existing users get affected.

I'd defer to my Database Administrator in cases like this, if there's no "official" DBA, I'd err on the side of caution. It's simple enough to create a development database, even for myself. On a team it's vital. Failing that, if you were insistent about hving only one database, you could prefix your development database tables with DEV_ and feel a bit better. Yes, that requires some code changes, but in development adding some variables during development $debug = true, etc, is usually worth the effort.

Lots of ways to approach this. It's very dependent on your situation.

Vote Up Vote Down

@Bryan171

Well, you can really mess it up the data. Imagine leaving off a where clause. Even if you have hourly backups, that would be a pain to fix.

Vote Up Vote Down