• dpm (unregistered)

    Test data.

  • Hanzito (unregistered)

    It also (strongly) suggests that id's aren't auto-generated, and are numbers converted to strings, probably starting out from '100000'.

  • Industrial Automation Engineer (unregistered)

    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.

  • (nodebb)

    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.

  • (nodebb)

    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.

  • Michael R (unregistered)

    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.

  • akozakie (unregistered)

    Why am I getting SCP vibes from this?

  • Patrick Tingen (unregistered)

    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.....

  • (nodebb)

    Where there are magic numbers, there must be a magic delete...?

  • (nodebb)

    INVEST. Stored procedures are not testable, therefore they don't exist :-)

  • codemky (unregistered)

    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!!

  • (nodebb)

    Table names anonymised or are we really seeing table1 and table2 in the database? That hints at ... many more horrors.

  • (nodebb)

    Stored procedures are not testable, therefore they don't exist :-)

    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.

  • (nodebb) in reply to Jaime

    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 :-)

  • (nodebb)

    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.

  • Verisimilidude (unregistered)
    Comment held for moderation.
  • markm (unregistered) in reply to LorenPechtel
    Comment held for moderation.
  • Lee Ann (unregistered) in reply to Steve_The_Cynic
    Comment held for moderation.
  • Jay (unregistered) in reply to dpm
    Comment held for moderation.
  • Bhumi (unregistered)
    Comment held for moderation.
  • Bhumi (unregistered)
    Comment held for moderation.

Leave a comment on “The Delete Procedure”

Log In or post as a guest

Replying to comment #:

« Return to Article