Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

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 model, mainly because I have a new employee with minimal skills and I'd rather not have him work directly with production data yet.

But for a long time I've worked directly with production data with minimal headaches, except for maybe a few errors creeping in here or there, things like spelling issues, bad alt text, links pointing to the wrong location. This seems to be due to a lack of peer review on my part, not because of working with live data.

So why is developing on the live site such bad practice?

share|improve this question
    
You could just duplicate the data you have on your production server on the development server. –  HoLyVieR Jul 14 '10 at 15:36
1  
mmmm... how do I upvote this question without appearing as supporting your way to do things directly with production data? :S –  vmarquez Jul 14 '10 at 16:50
2  
@vmarquez Is a question about a bad practice necessarily a bad question? –  Jim Jul 14 '10 at 17:14
    
No. It is not. I was about to vote-up because I had the feeling that this kind of questions are a great form to educate on best practices, and then, somehow, I got the idea on my mind that voting-up could be taken as a tacit approval on the bad practice, thus, provoking exactly the opposite effect. Now I think voting can be misleading... at least on some cases. –  vmarquez Jul 14 '10 at 18:04
1  
People vote on things for all kinds of different reasons. I don't take a vote as anything other than "this person got something out of this question." –  artlung Jul 14 '10 at 20:56
add comment

5 Answers

up vote 17 down vote accepted

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.

share|improve this answer
    
+1 on the sync process. We do that on demand here for our development. We also have a QA which is a more often synced area for final review of changes before they hit production. But we do run queries against production data sometimes, just because the issue is data related and very hard to replicate. –  Milner Jul 14 '10 at 20:23
    
+1 and sync can be tricky. In many cases, you'll want to do things as part of the Prod->Test push like scrub email addresses and names, etc to avoid accidentally emailing "Dear Rich Bastard" –  JasonBirch Jul 15 '10 at 5:27
add comment

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 .

share|improve this answer
add comment

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

  1. Development slows down your production box and creates vulnerabilities. What happens if you leave your computer unlocked and walk away?
  2. If you make a mistake people that visit your site can see it.
  3. 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.
  4. 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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.