@luke727 said:
Change the schema, and fuck anyone who gets in your way. Sure, it might look hard or tedious now; but if you don't change it now you are just going to get fucked even harder down the road. Or maybe you will get lucky and get hit by a bus, and the next schmuck in line will be "promoted" to this illustrious project. If people would just do it right the first time we wouldn't have to suffer through this non-sense. So do yourself and your successors a favor and fix your predecessors' mistakes sooner rather than later. If the powers that be won't let you fix it, threaten to quit.
I would see why this is a lost cause...and I tend to agree with the statement here. If you don't change it now you are almost certainly apart of the problem. Get yourself a test db and test app, change what you ought to, fix what breaks, repeat. You will spend less time doing that than trying to get a proper insert/update/delete to operate properly on that dataset. Especially when you think of a NL getting into that dataset as either appended to a name, or prepended some how...or worse, something after that NL (I know, proper data cleansing and checking). But if you don't ditch this now, you'll be seen as supporting it, forever!
@luke727 said:
If that doesn't work, burn the building down. I am not joking.
BTW...Don't forget your Swingline
Final thoughts:
If they really won't let you fix it, write a procedure that will rebuild that original (crap) dataset upon proper insert/update/delete of a real dataset...
i.e.
Original App -> Original Data
Insert/Update/Delete customer enhancements -> New (proper) Data -> Trigger (either actual DB depending on version, or in code is fine) Update old crap dataset
Then, rewrite each portion to use the proper dataset until the old is not used any longer.