Question

I was given the task of creating a stored procedure to copy every piece of data associated with a given ID in our database. This data spans dozens of tables. each table may have dozens of matching rows.

example:

table Account
pk = AccountID

Table AccountSettings
FK = AccountID

Table Users
PK = UserID
FK = AccountID

Table UserContent
PK = UserContentID
FK = UserID

I want to create a copy of everything that is associated with an AccountID(which will traverse nearly every table) The copy will have a new AccountID and UserContentID but will have the same UserID. the new data needs to be in its respective table.
🙂 fun right?

The above is just a sample but I will be doing this for something like 50 or 60 tables.
I have researched using CTEs but am still a bit foggy on them. that may prove to be the best method. MY SQL skills are…… well I have worked with it for about 40 logged hours so far 🙂

Any advice or direction on where to look would be greatly appreciated. In addition, I am not opposed to doing this via C# if that would be possible or better.

Thanks in advance for any help of info.

Answer 1

The simplest way to solve this is the brute force way: write a very long proc that processes each table individually. This will be error-prone and very hard to maintain. But it will have the advantage of not relying on the database or database metadata to be in any particularly consistent state.

If you want something that works based on metadata, things are more interesting. You have three challenges there:

1. You need to programmatically identify all the related tables.
2. You need to generate insert statements for all 50 or 60.
3. You need to capture generated ids for those tables that are more than one or two steps away from the Account table, so that they can in turn be used as foreign keys in yet more copied records.

I’ve looked at this problem in the past, and while I can’t offer you a watertight algorithm, I can give you a general heuristic. In other words: this is how I’d approach it.

1. Using a later version of MS Entity Framework (you said you’d be open to using C#), build a model of the Account table and all the related tables.
2. Review the heck out of it. If your database is like many, some of the relationships your application(s) assume will, for whatever reason, not have an actual foreign key relationship set up in the database. Create them in your model anyway.
3. Write a little recursive routine in C# that can take an Account object and traverse all the related tables. Pick a couple of Account instances and have it dump table name and key information to a file. Review that for completeness and plausibility.
4. Once you are satisfied you have a good model and a good algorithm that picks up everything, it’s time to get cracking on the code. You need to write a more complicated algorithm that can read an Account and recursively clone all the records that reference it. You will probably need reflection in order to do this, but it’s not that hard: all the metadata that you need will be in there, somewhere.
5. Test your code. Allow plenty of time for debugging.
6. Use your first algorithm, in step 3, to compare results for completeness and accuracy.

The advantage of the EF approach: as the database changes, so can your model, and if your code is metadata-based, it ought to be able to adapt.

The disadvantage: if you have such phenomena as fields that are “really” the same but are different types, or complex three-way relationships that aren’t modeled properly, or embedded CSV lists that you’d need to parse out, this won’t work. It only works if your database is in good shape and is well-modeled. Otherwise you’ll need to resort to brute force.