Restoring takes lots of time and disk space, particularly if you have to provision many copies. The data is now perfectly realistic, but you still have problems. If the customer’s address is just a random string, rather than a valid address, then this feature cannot be tested.ģ) Restore a backup of production. For instance, your application may have a feature where it shows a Google Map of a customer’s address. Also, this data will not be realistic or meaningful.
#Sample data generator sql server 2012 full#
The data quantity is realistic, but generating this database will take a long time and still requires the full disk storage requirements. And it will never be big enough for load-testing.Ģ) Test against automatically-generated data, e.g. Hand-crafting test data is fiddly, tedious and incredibly slow, with the data rarely resembling real data.
But the average production database is between 100Gb and 1TB, and often locked down for data privacy reasons.ġ) Test against a hand-crafted test database. The reality is that DBAs, developers and testers benefit immensely from access to production-like databases for testing application changes, testing schema changes, and testing ad-hoc queries. It seems that the desire to have realistic data will for many trump the desire to keep sensitive data out of development and test environments. Many of these respondents concede that they should be removing sensitive data, but aren’t. In a recent survey run on community site SQL Server Central, 58% of respondents admitted that their test database is an exact copy of their production database.
0 kommentar(er)
