What are the [dis]advantages of using a key/value table over nullable columns or separate tables?

Question

I\'m upgrading a payment management system I created a while ago. It currently has one table for each payment type it can accept. It is limited to only being able to pay for

Answer 1

Perhaps you should look this question

The accepted answer from Bill Karwin goes into specific arguments against the key/value table usually know as Entity Attribute Value (EAV)

.. Although many people seem to favor EAV, I don't. It seems like the most flexible solution, and therefore the best. However, keep in mind the adage TANSTAAFL. Here are some of the disadvantages of EAV:

• No way to make a column mandatory (equivalent of NOT NULL).
• No way to use SQL data types to validate entries.
• No way to ensure that attribute names are spelled consistently.
• No way to put a foreign key on the values of any given attribute, e.g. for a lookup table.
• Fetching results in a conventional tabular layout is complex and expensive, because to get attributes from multiple rows you need to do JOIN for each attribute.

The degree of flexibility EAV gives you requires sacrifices in other areas, probably making your code as complex (or worse) than it would have been to solve the original problem in a more conventional way.

And in most cases, it's an unnecessary to have that degree of flexibility. In the OP's question about product types, it's much simpler to create a table per product type for product-specific attributes, so you have some consistent structure enforced at least for entries of the same product type.

I'd use EAV only if every row must be permitted to potentially have a distinct set of attributes. When you have a finite set of product types, EAV is overkill. Class Table Inheritance would be my first choice.