August 19, 2014 at 1:42 am
When I write code in a database, it often turns out that some time later, the code is no longer needed. The app calling it changes, and the view or procedure is no longer used. It doesn't really hurt anything to leave them, but clutter makes it harder to manage the database.
Are there any good tricks for keeping track of this, and removing what is no longer needed? I've had both sides of the problem - leaving unnecessary junk, and removing stuff that isn't junk. I can't even just scan the app for a name, because some calls are built by code, and a literal string containing a name doesn't exist.
August 19, 2014 at 5:14 am
Yep, that's a problem... Not much that's easy to be done about it, either. There's really only one way to get it done, and it's expensive in terms of overall effort. Somebody has to agree to let folks spend the time documenting every single table, column, function, view, sproc, trigger, CLR assembly, and index in the entire database, and establish the owner & developer responsible for each and every one. The most important question to be answered, however, is the "why" that object exists. That all needs to exist in what some folks call a "data dictionary", but whatever you call it, if you don't have it, you're going to have the problem you described, pretty much forever.
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
August 19, 2014 at 7:02 am
I sort of figured that was the case, but thought maybe someone here would have some tricks they've dreamed up. This whole system is entirely my own creation, so I can't even blame someone else for the mess. But it's not all that bad - only a few hundred objects total, and I've come up with a fairly usable schema naming system, so it's manageable, just not quite as tidy as I'd like. Thanks anyway.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply