Привет!
Имеется куча однотипных интеграций, допустим биллинг. Но у каждого интегратора есть свои заморочки. Кто-то требует хранить дополнительные поля, кто-то нет. Возникает вопрос, какой вариант станет лучшей реализацией?
Я вижу 3 варианта:
1 - каждой интеграции своя таблица. Плюсы - таблица создана под конкретного интегратора, через некоторое время не понадобится голову ломать "а используется ли это поле где-либо. Минусы - чем больше интеграций, тем больше таблиц, будет много "хлама" в структуре. Ну и общий интерфейс реализовать не получится - тоже минус .
2 - единая таблица "в ширину" - одна таблица, где по необходимости добавляются новые поля для интеграции, в случае, если нельзя найти аналогов среди других полей от предыдущих интеграций - плюсы - избавляемся от минусов первого варианта, минусы - в будущем фиг поймешь какая интеграция использовала какие поля (но по сути для этого есть код, а в идеале ещё и документация)
3 - единая таблица с общими параметрами и json-полем - казалось бы самый изящный вариант, дополнительные поля гарантированно не будут участвовать в выборках, стало быть страшного ничего не произойдет. избавляемся от всех минусов, приобретаем новый - теперь наша структура не наглядная.
Я думаю между 2 и 3 вариантом, хотелось бы узнать, какие плюсы и минусы я не учёл, и какой вариант будет "хорошей практикой" для решения этой задачи? быть может я вообще в другую сторону думаю:)
3 - единая таблица с общими параметрами и json-полем - казалось бы самый изящный вариант, дополнительные поля гарантированно не будут участвовать в выборках, стало быть страшного ничего не произойдет. избавляемся от всех минусов, приобретаем новый - теперь наша структура не наглядная.
В табличном представлении общие данные.
Для детального представления парсер достает данные из этого поля, так что все наглядно и расширяемо.
В качестве сахара в бизнес логике используйте наследование.
Вариант с json - самый правильный, настроечные поля нет смысла плодить по отдельным ячейкам, наглядность же обеспечивает вьюшка с самым примитивным разбором json, ибо смотреть сырцы в базе все равно так себе занятие.
Есть еще 4 вариант, одна таблица с общими данными, и вторая таблица с доп данными id, payment_id, param_name, param_value, со связью один ко многим. То есть к каждому платежу может быть добавлено произвольное количество доп параметров.
Плюс в отличие от json в том, что можно делать выборки по этим параметрам
Не, так говно полное получается. Это ладно если у тебя 2 или 3 платежки, а если 10? Там столько доп полей будет, что потом рехнешься вспоминать что и откуда
Станислав, в json поле писать не {foo: bar}, а {provider: {foo: bar}}. Тогда можно будет искать сразу по полям провайдера.
Без префиксов запрос будет (provider_id = 1 AND json @> {foo: bar}) OR (provider_id = 2 AND json @> {doo: boom})
С префиксом - json @> {provider1 :{foo: bar}} OR json @> {provider2 :{doo: boom}}
Запросы по json чуть сокращаются, но в среднем геморроя больше. Ну и главный вопрос - нафига по json искать? ))
Через таблицу линковок внешних и внутренних полей.
Таблицы:
1. Список поставщиков данных (id, название, ...)
2. Список полей внутри вашей системы для внешних данных (id, название_поля, назначение, .....)
3. Поля поставщиков (id, id_поставщика, конкретное_входное_поле_поставщика, описание_поля, regex-фильтр, количество_ошибок_фильтра,....)
4. Линковка полей (id, id_поля_поставщика, id_поля_в_вашей_системе, когда_слинковано, кем_слинковано,....)
