Problem:
Recently faced with an application that is deep in maintenance I was asked to de-identify some demographic data for a new training environment. One aspect of the data in the database is stored in a decent sized XML blob of ~10Kb. The XML blob had some of the data that needed to be modified - names, addresses, phone numbers etc. This data is also spread out to other reaches of the database in relatively harmless tables.
Solution 1Recently faced with an application that is deep in maintenance I was asked to de-identify some demographic data for a new training environment. One aspect of the data in the database is stored in a decent sized XML blob of ~10Kb. The XML blob had some of the data that needed to be modified - names, addresses, phone numbers etc. This data is also spread out to other reaches of the database in relatively harmless tables.
Do data manipulation at the data store with SQL scripts. To be honest, 90% of the work is done in SQL scripts to remove unwanted data, shuffle names and addresses, randomly change DOBs etc. When doing bulk deletes and manipulations the flexiblity to easily disable indexes and triggers lends itself to TSQL and intimate database relations. However when facing the data in the XML blob and things became a little cumbersome in TSQL. So I looked to finish the job with...
Solution 2
The current application has a data model and data access, surely that can be reused. The option of taking the XSD and load/save methods of this old (Vb.Net 1.1, 1 assembly (!) ), monolithic ASP.Net website and wedge it into a console app to manipulate the data seems good on first glance. It really only took about 5 minutes of going down this path to feel a pain that really shouldn't be felt. (Think Datasets, SqlCommand, SqlDataReader and friends). Spaghetti code like this just can't be plied apart from the in-tree custom framework that it lives with. So in comes...
Solution 3
Enter RAD. I opened up VS2008 and took the following steps - new console project, register database in Server Explorer, new Linq-to-SQL designer, drag the database table to the designer. Then it was a simple case of creating a database context, iterating the rows, using XPath to manipulate the Xml and submitting the changes to the database. The end solution was less than 30 lines of code and took less than 15 minutes.
So what was cool about this? Well, I didn't write a single line of 'grunt work' - no database access, domain objects, readers or mappers - it was all done for me. I distanced myself from the mechanics of the task at hand and focused on the heart of the problem, which was updating the data.
So what was cool about this? Well, I didn't write a single line of 'grunt work' - no database access, domain objects, readers or mappers - it was all done for me. I distanced myself from the mechanics of the task at hand and focused on the heart of the problem, which was updating the data.
What I learned came back to the old adage of 'using the right tools for the job'. RAD tools don't fit every application or architecture, but in my mind for throw away utilities like I was writing they provide the perfect solution.
