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
