Separating Demo data in Live system

Question

If we put aside the rights and wrongs of putting demo data into a live system for a minute (that's a whole separate discussion!), we are being asked to store some demo data in our live system so that it can be credibly demonstrated without the appearance of smoke + mirrors (we want to use the same login page for example)

Since I'm sure this is a challenge many other people must have - I'd be interested to know what approaches have people have devised to separating this data so that it doesn't get in the way of day to day operations on their systems?

As I alluded to above, I'm aware that this probably isn't best practice. :-)

Answer 1

Can you instead, segregate the data into a new database, and just redirect your connection strings (they're not hard-coded, right? right?) to point to the demo database. This way, live data isn't tainted, and your code looks identical. We actually do a three tier-deployment system this way, where we do local development, deploy to QC environments that have snapshots of the live data every few months, and then deploy to live when testing is complete.

Answer 2

I've often seen it on certain types of live systems. For example, point of sale systems in a supermarket: cashiers are trained on the production point of sale terminals.

The key is to carefully identify the test or training data. I wouldn't say that there's any explicit best practice for how to model this in a database - it's going to be applicaiton specific.

You really have to carefully define the scope of what is covered by the test/training scenarios. For example, you don't want the training/test transactions to appear in production reports (but you may want to be able to create reports with this data for training/test purposes).

Answer 3

FWIW, we're looking at using Oracle's row level security / virtual private database feature to seperate the demo data from the rest.

Answer 4

Completely disagree with Joe. Oracle has a tool to do this regardless of implementation. Before I read your answer I was going to say VPD... But that could have an impact on Production.

Remember Every table in a query changes from

SELECT * FROM tableA

to

SELECT * FROM (SELECT * FROM tableA WHERE Data_quality = 'PROD' <or however you do it>

Every table with a policy that is...

So assuming your test data has to span EVERY table, every table will have to have a policy and every table will be filtered before a SQL can begin working.

You can even hide that column from the users. You'll need to write the policy with some deftness if you do. You'll have to create that value based on how the data is inserted and expose the column to certain admin accounts for maintenance.