- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Test data.
Admin
It also (strongly) suggests that id's aren't auto-generated, and are numbers converted to strings, probably starting out from '100000'.
Admin
this is to keep the print-out of said tables on one page. (which then can be put on a wooden table, photographed, emailed, and end its life-cycle bij a rule to trash any communications containing the magic numbers. all in all, a very reasonable workflow.
Admin
Those IDs might be special magic IDs created by some sort of testing procedure (yeah, I know, testing on Production), and therefore they must be ruthlessly hunted down and eliminated.
Admin
I can't decide whether I'm more offended by the use of magic numbers, the wrong data type for an integer, or the "sp_" prefix on the procedure names.
Admin
I was once working at a bank where the previous guy added lots of if-statements to the Stored Proc. The if-statements returned different columns/structure of the data. All if-statements compared a variable with a ISO 8601 date. The value for the variable itself was not passed in but set at the top of the SP with the current date/time. Basically it was his way of suppressing old code-paths without commenting them out or removing them completely and only being able to look them up in SVN (git was not a thing back then). But still be able to see when those different structures were returned. It was a right mess.
Admin
Why am I getting SCP vibes from this?
Admin
Could it be that we are only looking at a part of the primary key and that table1 and table2 are - in fact - some sort of "one true lookup table". The table might have a compound primary key consisting of two fields; ID and SUB_ID or something to store more generic things. The pseudo-numeric value for ID could come from some preprocessor value that gets translated to a number.
Something like ID = '109369' means customer-type. The table could be filled with values like: ID = '109369' SUB_ID = "regular" DESC = "Regular customer" ID = '109369' SUB_ID = "special" DESC = "Special customer" ID = '109369' SUB_ID = "on_hold" DESC = "Customer on hold" etc
For the record: I think this is horror. But I've seen it more than once.....
Admin
Where there are magic numbers, there must be a magic delete...?
Admin
INVEST. Stored procedures are not testable, therefore they don't exist :-)
Admin
varchar(6) primary key? Let’s hope this table doesn’t need room to grow The stored procedures smell like a way to grant constrained delete permissions to a user though. Why those two IDs remains anybody’s guess!!
Admin
Table names anonymised or are we really seeing table1 and table2 in the database? That hints at ... many more horrors.
Admin
Sure they are. With Visual Studio database projects, Azure support for spinning up a containerized database from a project in a few seconds, and the tSQLt testing library, database unit testing is now on par with where the rest of the world was in about 2003.
Admin
For testing you need reliable error propagation which means tracking for each statement dozens of error codes, so...
INVEST: Store procedures with proper error propagation for make them remotely testable are not small, therefore they don't exit :-)
Admin
I have a slightly more sane hypothesis than Steve The Cynic:
They're magic values, but this is a legitimate workflow. Some ancient import process creates them, something is done with them and this cleans them up to repeat the cycle.