Предположим, что существует система с двойным учетом:
Я предпочитаю последнюю модель с нормализованным Transaction.
Есть длительные сложные операции со многими состояниями. Одна большая транзакция влияет на многие доп. учетные записи (или даже многие бухгалтерские книги), вы можете сторнировать (публиковать напротив Transaction s), добавлять новые транзакции, такие как комиссия, штраф или перераспределять деньги из всех участвующих доп. транзакции по счетам / бухгалтерским книгам при изменении состояния. Должны хранить ссылки на Transactions и не дублировать Amount в этих таблицах процессов c. 
Дополнительные примеры:
Простой пример ApplicationTransaction - это Bet которые состоят из нескольких Pledge с, когда вы берете некоторое обеспечение от каждого участника. Каждый участник даже имеет различные активы на карту, и House может взять многие из них, чтобы удовлетворить некоторые требования. Я имею в виду обобщенную таблицу c ApplicationTransaction с D iscriminator и многими определенными c таблицами.
и ApplicationTransaction таблицу со столбцом State, ссылающуюся на множество транзакций с двойной записью, которые она выполняет. В течение времени жизни ApplicationTransaction он может публиковать (делать Transaction s) изменения своего состояния, но не всегда. Например, Bet берет обеспечение и освобождает его, когда время Bet истекло, при некоторых обстоятельствах оно перераспределяет начальные суммы, удерживаемые этой операцией, но некоторые из ее состояний не публикуются.
A Lottery (что является наиболее вымышленным вариантом использования здесь) может быть примером ApplicationTransaction, который затрагивает многие аккаунты, он начинается и заканчивается массивным «сбросом» выигрышей. Каждый экземпляр имеет свои собственные значения атрибута, свойства которого следующие: stati c.
Другой вариант использования - Trade между двумя доп. счета, где Хаус может быть посредником, должны брать активы с каждой стороны, перемещать их на специальные LedgerAccount|XYZ|AL|Escrow|, по одному на ApplicationTransaction.Type, а не на экземпляр. Сохраняйте записи о передачах, связанных с указанным c Trade экземпляром, может длиться некоторое время, иметь несколько состояний, атрибутов, разные результаты для доп. Владельцы счетов, которые могут быть штрафом для одной стороны и погашением для другой. Без книги заказов или соответствующего двигателя. Такой процесс обмена имеет несколько состояний, и в разрешении спора может быть задействован другой контрагент, если произойдет такой State переход. Оба участника должны пометить Trade чем-то вроде Payment Received (при условии, что оплата производится вне системы). Это состояние перехода. Система может взимать плату с каждого участника.
Это не одна запись Transaction. Группа из них. Например, если мне нужно внести определенную сумму в условное депонирование, я могу положить X * Emeralds и X * Diamonds, чтобы встречаться с принцессой. Таким образом, он не только публикует много (AssetType, Amount, AccountNo) (N * активов * 2 участников), но и публикует в Income LedgerAccount. Предположим, что мы совершаем сделку за интервал Assets.
. Можно также добавить таблицу, которая ограничивает возможные переходы для каждого типа операции, чтобы мы могли добавлять ограничения. Я рассматриваю его как копию таблицы поиска состояний с дополнительными ссылками на столбцы NextState, таким образом, он определяет набор доступных состояний. Однако за рамками этого вопроса.
Я, очевидно, не решаю здесь новую проблему, поэтому вопрос в том, что явно не так с моим дизайном и как будет выглядеть правильное направление.
Возможно с моей стороны все еще есть недоразумение, но я не думаю, что каждый экземпляр варианта использования приложения должен производить одноразовые LedgerAccounts, потому что мы не создаем новые HouseCash для каждого варианта использования Deposit и Withdrawal. Депозит / Снятие также относится к категории ApplicationTransaction, с несколькими переходами между состояниями (например, отклонено обработчиком платежей). В реальном приложении у вас есть специальные таблицы для обработки, есть способ оплаты и сумма и т. Д. c.
В противном случае такой подход приведет к сотням тысяч одноразовых LedgerAccounts. Вопрос не в том, чтобы сделать универсальную модель системы общего назначения для Вселенной, а в том, правильное ли направление. Не уверен, что мы должны вести разовые счета, как я уже говорил, я вижу Account и LedgerAccount как нечто, необходимое для получения отчетов House, ведения учетных записей клиентов, иначе это выглядит так же глупо, как определение учетной записи для каждого ядра ЦП в AWS EC2.