| || |
Looking for suggestions on testing database separation
I have a upcoming project to test the results of a database separation. In this project all the entites have a geographical address. The database is being cut in two. All entities in region 1 go in database A and all entities in region 2 in database B. The programmer is accomplishing this by creating two copies of the database, A and B, and simply deleting from database A all entities in region 2. For database B similar but opposite logic is applied.
My problem is how to approach testing the results to insure no data was lost or misplaced. The database, tho not huge my modern standards, but is complex, containing over 40 tables.
My initial idea is to start by simply counting entities in each region in the original database and the doing the same in each of the new databases. But where to go from there.
Any suggestions would be apprecated
Originally Posted by CoffeeGuy
My advice is don't try to test it full scale. Try testing on a smaller scale first. If the devs are using an ORM, build the database fresh with the ORM, then create a script that can insert say a couple thousand known entries of varying kinds with known properties. If not with ORM, then do some prelim queries on a sub set of records, with varying characteristics, drop the rest, and test against a smaller scale. You can do this by creating a sanitized copy and say dropping all accounts under a certain date range, and clean up any stray records before testing. This will get you a smaller subset of the database of known inputs and outputs you can test against.
You don't want to do the test full scale against production data because there's no way you should know everything that should happen. And to migrate a full production database can take much longer than you have time to test many iterations.
As for what to test, you might want to create an entity relation diagram to the database and catalogue any foreign key dependencies, indexes, stored procedures, and triggers. You'll need to test the data integrity of those as they may have unexpected side effects. 2nd, you'll want to get an initial performance baseline via load testing the slimmed down database. Then doing a performance of the sharded setup to ensure no unexpected performance bottlenecks are introduced. Then with anything database deploy, it's good to always have a rollback strategy, and be able to test that against your small scale database where you know what all the data should look like.