Credit Card Types



  • [Okay, on second thought, the details of where I encountered this stored procedure are being stripped right out to protect the guilty.]

    Suffice it to say, I was working on a modernization and re-write of an administrative interface of a website that handles a LOT of money.   The entire thing was a debacle, but my favorite part was this credit card authorization page...

    There were 7 or 8 payment types in the payment types table in the database, only 3 of which were credit cards.  The payment type ID and Name were the only columns in that table... And yet, somehow, when authorizing a credit card, it was hitting the database to fill this drop down list but only filling it with the 3 credit card types.  I dove into the stored procedure to find out how it was doing this wizardry, automagically separating the credit cards from the other forms of payment:


    SELECT PaymentTypeID, PaymentTypeName

    FROM PaymentTypes

    WHERE PaymentTypeID IN (2, 3, 4)


    ...needless to say, I hard-coded the drop-down.



  • It does seem silly to hit the DB for this, but is it really that huge a problem? Seems like a simply query like that should be cached by the DB. Then again, I stay away from database programming altogether so I'm probably full of crap.

     



  • adding a enum column to define it's type would perhaps have been better in the long run. (creditcard, direct debit, voucher etc.. etc..)



  • I agree, but adding columns to the database was outside of the scope of the revision for which I was authorized.  Stored procs yes, but if I had let myself even look at the database structure itself I'dve been changing the whole thing. :S


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.