Protection for MySQL database

[blackbird]

I am a small business owner (not a programmer) wondering if it's possible to protect my customer & order data in my MySQL database. I have heard that you cannot protect individual tables only an entire database but need to give a backup/copy of my database to a programmer to work with. Does anybody have any tips or ideas on how to do this? A friend told me to delete all but 5 lines in the customer table, edit those 5 lines to hide real data, then copy those 5 lines to re-create 15-20 lines of the database so programmer will see structure but no data. If this is a good idea or is possible, can anybody tell me how to do this? Thank you.

[raf]

Well, to develop, there is no problem if you create fake datarecords.
However, don't blame the developper if later turns out that some of the actual values create unforseable problems (because they are considerably longer, contain uncommon characters, are duplicated, ...)
It's also difficult to preview performance in a production-environment after implementation, if you only worked with a tiny sample of the actual data while developping and testing.
So if you fake the data, then they should be representative and in all aspects as close to the actual data (number of records, valueformats, variation etc etc).

[Kiwi]

In my job, we have had numerous problems with inconsistencies between our development, test and production environments. For example, a process that took a long time to run in the test environment (and, consequently, was the target of a lot of development effort) turned out to run very quickly in production -- simple because it was run more frequently on smaller active datasets. Similarly, testing on a limited dataset gives false times on select, so you have no idea if your application is actually performing satisfactorily. If you don't have a full range of possible data in your test/dev system, then going live becomes a try and hope approach.

You'll almost certainly find that there are development issues when you go live so, no matter how hard you try, the developer is likely to get access to your live data at some point in the cycle. You're far better to focus on finding a developer you can trust and putting contracts in place to ensure (and insure) that trust than messing around trying to create a satisfactory set of test data.

Where you do need good test data is to deal with unknown future values -- something that is very hard to forcast. In most cases, your historical data is the most reliable predictor.