Re: When should stuff be stored in a database?

From: Marshall Spight <mspight_at_dnai.com>
Date: Mon, 14 Apr 2003 07:01:27 GMT
Message-ID: <b1tma.177949$OV.258307_at_rwcrnsc54>


"Paul Linehan" <paul_at_not.a.chance.ie> wrote in message news:q05k9vs6n3h754rei5lqbv94n4c313077n_at_4ax.com...
>
> Create TABLE OigePayment
> (
> PaymentType VARCHAR(12)
> );
>
> INSERT INTO OigePayment Values('Cash');
> INSERT INTO OigePayment Values('Cheque');
> INSERT INTO OigePayment Values('Draft');
> INSERT INTO OigePayment Values('Direct Debit');
> INSERT INTO OigePayment Values('Agent');
> INSERT INTO OigePayment Values('Laser'); // a debit card
> INSERT INTO OigePayment Values('Credit Card');
> COMMIT;
>
> Now, it is very unlikely that another form of payment is going to be
> invented any time soon, so I am wondering whether it is better to hard
> code the values for this parameter into the app?

In general, it is better to avoid hard coding values into "the" app. For one thing, other apps you don't anticipate may come later, maybe even written in another language than the one you're using now. For another thing, my experience with "very unlikely" scenarios is that they take anywhere from 6 months to a year to happen. :-) Yes, even for payment types.

You should also declare the table such that duplicates are disallowed.

Marshall Received on Mon Apr 14 2003 - 09:01:27 CEST

Original text of this message