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

Есть платежные агенты, которые принимают платежи от пользователей и отправляют их сервисному провайдеру.
У каждого платежного агента есть свой уникальный идентификатор и свой алгоритм работы.
Кто-то работает в пакетном режиме — раз в сутки присылает реестр платежей, в котором указаны лицевые счета, суммы и другая информация. Платежный шлюз должен принять этот реестр, проверить данные и провести валидные платежи.
Кто-то работает в интерактивном режиме — платежная система подключается к платежному шлюзу непосредственно в момент проведения платежа, передает на шлюз информацию, шлюз ее проверяет и подтверждает или отклоняет операцию. Для контроля платежная система раз в сутки присылает реестр платежей, по которому осуществляется сверка.

Не могу определиться с тем, как должны храниться эти данные.
Пока прикидки такие.

Справочник платежных агентов
payment_agent ТипОписаниеpayment_agent_idПервичный ключcodeИдентификатор агентаnameНаименование агента

Список реестров
payment_registry ТипОписаниеpayment_registry_idПервичный ключpayment_agent_idFK на payment_agentclockdatetimeДата/время получения реестраstatusСтатус реестра (черновик, ошибочный, удаленный, принят, обработан)reg_datedateДата реестра (год, месяц, день)reg_numberintПорядковый номер реестра за текущую дату (если на конкретную дату пришло несколько реестров)reg_serialintПорядковый номер реестра (глобольный или в пределах года)reg_countКоличество строк в реестреreg_sumСумма реестраreg_fileИмя файла реестра, если применимо

Список платежей
payment_item ТипОписаниеpayment_item_idПервичный ключpayment_agent_idFK на payment_agentpayment_registry_idnullableFK на payment_registry, для интерактивных платежей может не заполняться или заполняться потомsessionИдентификатор транзакции между платежной системой и шлюзомclockdatetimeДата/время регистрации платежа у агентаactТип запроса (запрос информации, проверка параметров, проведение платежа)accountЛицевой счет плательщикаtypevarcharТип платежа (определяется платежной системой, например наличный/безналичный)amountСумма платежаoriginatorИнициатор платежа (например имя кассира, если платеж был проведен через кассу)pay_...Дополнительные атрибуты по платежуret_clockdatetimeДата/время обработки платежа на шлюзеret_codeКод ответа (ошибки)ret_textТекст ответа (ошибки)ret_balanceТекущий баланс лицевого счетаret_amountТребуемая или желательная сумма платежа (если применимо)ret_...Дополнительная информация, передаваемая при проверке или запросе информацииpay_idУникальный идентификатор платежаpay_clockdatetimeДата регистрации платежаpay_clientИдентификатор клиента в биллинговой системе, на счет которого зачисляется платежstornobooleanПлатеж сторнирован?storno_clockdatetimeДата/время сторнирования платежаstorno_reasonПричина сторнирования платежа

Ничего не упустил?

________________________
Мы смотрим с оптимизмом...
...в оптический прицел.

Модератор: Тема перенесена из форума "Программирование".

ScarferNVЧестно говоря не пойму, как реестр платежи связаны с реестром...
Если работа осуществляется в офлайн-режиме, то реестр платежей и содержит непосредственно сами платежи. Тогда реестр будет родительской таблицей для платежей.
Если работа осуществляется в онлайн-режиме, то платежи приходят и проводятся вообще без реестров. На следующий день приходит реестр платежей (в котором будут фигурировать назначенные идентификаторы), который нужно сверить с фактически принятыми платежами.

Кот МатроскинТаблица платежей странная, по-хорошему там проглядываетсся 3-4 таблицы (даже если не раскрывать в таблицы поля "дополнительная информация")
А стоит ли усложнять?
На платежном шлюзе нет состояний, это stateless-алгоритм. Шлюз принял запрос, проверил данные и либо подтвердил запрос (проведя платеж), либо отклонил запрос (указав причину). Все, больше с этими данными работа осуществляться не будет, их нужно сохранить в БД для архивных целей.

384 таблицы это как-то экстремально.
А можно подробности?
Или для каждого поставщика/агента свой набор таблиц?

MasterZivКакие ?

Зачем такая нормализация?
Или для каких целей нужно столько таблиц?

Я могу придумать, скажем, полсотни справочников. Еще пару десятков сущностей, штук 80 таблиц для истории и состояний. Допустим еще под сотню таблиц на связи, если там какая-нибудь 4НФ.
Но все равно получается почти вдвое меньше.