Q:

When is it necessary to add a table in the database for lookup values

just looking for some general direction/best practice about when to use a lookup value table. Lets say I have a table with transactions/payments in it which has the following columns:
transactions

transaction_id
order_id
amount_paid
payment_status
payment_type

Ok lets say payment_type can be one of 3 options ('credit card', 'direct credit', or 'international money transfer'). Currently for every table row this payment_type field is being stored as text. Now is it better to store this value as text or make a lookup table for it and store the foreign key back in the transactions table?
E.g.
payment_type

payment_type_id
payment_type_name

transactions

transaction_id
order_id
amount_paid
payment_status
payment_type_id

Now my thoughts are this field is tightly coupled with the web application, so if more payment types are added in the future, the application will likely have to change to accommodate it. It would be just as easy to add another payment type as text e.g. 'paypal' or add another entry into the lookup table. The various payment types could be stored within the website code in an array.
The benefits I can see of using the lookup table are less overall data in the database (storing a key rather than text). Disadvantages are maybe slightly slower querying as it has to do another join on the data?
So what's the best practice here?

A:

is is necessary...

I'd say that in this case it is best practice to have the lookup table.
if you have a simple active/inactive or Yes/No column you can just use a char(1) and a check constraint or a bit, but it is best to have a lookup table if you are representing anything more complex.
You can then use this table for the user form input (populating the select box, etc.)
this will flatten and shrink the column, which will allow more rows per page, and help cache memory usage of the main table.

