Сохранять исторические данные

Question

Я пишу стандартное приложение для базы данных с поддержкой базы данных. Предположим, что я работаю с банковскими счетами, а также с «Решениями». Решение - это выбор, который пользователь берет за перемещение денег с одного счета на другой. Каждое решение принимается в определенный день. Решение может иметь одну или несколько «исходных учетных записей», и каждая «исходная учетная запись» будет иметь одну или несколько «учетных записей». Мы называем их исходными учетными записями, потому что деньги покидают учетную запись ... Также каждое решение и учетная запись имеют соответствующую информацию, такую ​​как имена, баланс и т. Д.

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

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

Answer 1

Вы можете сделать копию вместо записи. Просто покажите «Решения» в прошлом месяце и дайте пользователю выбрать и отредактировать их. Но когда он «сохраняется», вы должны вставить новую строку вместо обновления. Это делает «Решения» в прошлом месяце скорее шаблоном за эти месяцы, чем абсолютным.

Выбор между двумя, вероятно, будет сильно зависеть от того, что вы делаете, если пользователь не хочет «Решения» в прошлом месяце. Вы удаляете лишние строки? Они автоматически вступают в силу без ввода пользователем или деактивируются при создании и т. Д.

Другим вариантом может быть механизм управления версиями. Каждое «Решение» получает Идентификатор и версию (или Дата вступления в силу). Решение каждого месяца имеет как DecisionId, так и DecisionVersion. Обновление «ключевых полей» решения приводит к созданию новой версии. Это ведет историю изменений и линий для каждого «Решения».

Управление версиями имеет смысл для меня в сценарии типа «Автоматический план экономии». Вы должны создать «Решение» с именем «Автоматический план экономии», и вы сможете изменить количество, исходные учетные записи и т. Д., Но они все равно будут частью «Автоматического плана экономии».

Answer 2

Ваши «Решения» считаются транзакциями в бухгалтерском учете, разделенными на T accounts, когда транзакция имеет несколько источников дебетования/кредита.

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

Большинство учетных систем, с которыми я работал, позволяют планировать исходящие транзакции (IE: ипотека, автокредит, медицинская страховка) - нет вреда при вставке новых записей на основе предыдущей информации, ,