Каковы [dis] преимущества использования таблицы ключ / значение по сравнению со столбцами, допускающими значение NULL, или отдельными таблицами?

Я обновляю систему управления платежами, которую создал некоторое время назад. В настоящее время у него есть одна таблица для каждого типа оплаты, который он может принимать. Он ограничивается возможностью платить только за одну вещь, которую данное обновление призвано облегчить. Я просил совета относительно того, как мне его разработать, и у меня есть следующие основные идеи для работы:

1. Имейте по одной таблице для каждого типа оплаты, с несколькими общими столбцами для каждого. (текущий дизайн)
2. Координировать все платежи с помощью центральной таблицы, которая принимает общие столбцы (объединение идентификаторов платежей независимо от типа) и определяет другую таблицу и идентификатор строки, в которых есть столбцы, специализированные для этого типа платежа.
3. Имейте одну. таблица для всех типов платежей и обнулить столбцы, которые не используются ни для одного данного типа.
4. Используйте идею центральной таблицы, но хранить специализированные столбцы в таблице «ключ / значение».

Мои цели: не до смешного медлить, максимально самодокументировать и максимизировать гибкость при сохранении других целей.

Мне не нравится 1 во многом из-за повторяющихся столбцов в каждой таблице. Он отражает классы типов платежей, наследующие базовый класс, который обеспечивает функциональность для всех типов платежей ... ORM наоборот?

Я больше всего склоняюсь к 2, потому что он такой же "безопасный по типу" и самодокументируемый, как и текущий дизайн. Но, как и в случае с 1, чтобы добавить новый тип платежа, мне нужно добавить новую таблицу.

Мне не нравится 3 из-за его «потраченного впустую места», и не сразу понятно, какие столбцы используются для какого платежа типы. Документация может несколько облегчить эту проблему, но моя компания ' внутренние инструменты не имеют эффективного метода для хранения / поиска технической документации.

Я выдвинул аргумент в пользу 4, что он избавит от необходимости изменять базу данных при добавлении нового метода оплаты, но он страдает даже хуже, чем 3 делает из-за отсутствия ясности. В настоящее время изменение базы данных не является проблемой, но это может превратиться в логистический кошмар, если мы решим позволить клиентам в будущем вести собственную базу данных.

Так что, конечно, у меня есть свои предубеждения. Есть ли у кого-нибудь идеи получше? Как вы думаете, какой дизайн подходит лучше всего? На каких критериях следует основывать свое решение?