В прошлый раз я попробовал рассказывать некоторые мелкие детали, связанные с планированием авторизации и прав доступа, которые обычно забывают при планировании структуры финансовой системы.
На этот раз я хотел поговорить о проблеме, устранение которой на более поздних этапах проектирования финансовой системы будет наиболее дорогостоящим и трудоемким.
Давайте посмотрим на пример.
Допустим, в базе данных вашей системы есть несколько таблиц.
Одним из них является справочник юридических лиц.
Как разработчик/аналитик, вам необходимо разработать функциональные возможности для работы с документами определенного типа.
Например, предположим, что вам необходимо разработать функционал по созданию и редактированию платежных поручений.
Допустим, 1 платежное поручение должно иметь следующие поля: 1. уникальный номер 2. дата и время создания 3. дата и время оплаты 4. юридическое лицо (контрагент), которому была произведена оплата 5. сумма 6. тип платежа Сразу отмечу, что практически никогда не следует связывать уникальный номер документа с идентификатором записи в таблице базы данных.
Дело здесь в следующем: пользователи склонны совершать ошибки.
Логика пользователей порой весьма своеобразна; например, им время от времени проще удалить неправильно созданный документ и создать новый (особенно это касается новых сотрудников, которые боятся «напортачить»).
После таких действий у вас в системе останется много пустых «дырок» между номерами документов.
Казалось бы, мелочь, но любая проверка «заинтересованных» лиц обнаружит в этом тайный умысел.
(Если хотите реальных примеров, погуглите «Прайм-ТАСС подал иск против мэрии Москвы».
Вся их доказательная база - номера документов были в порядке, но в открытом доступе находится только часть из них).
Лучше всего, на наш взгляд, присвоить вновь созданному документу номер = максимальный уникальный номер в системе для данного типа документа + 1. Но вернемся к нашему примеру.
Обратим внимание на поле №4 – юридическое лицо.
Поскольку у нас есть справочник юридических лиц, то очевидно, что в этом поле нужно написать ссылку на запись в этом справочнике.
Теперь представим себе несколько возможных ситуаций: 1) Платежное поручение создано в 2009 году.
Оплата произведена ООО «Бед».
В январе 2010 года компания была переименована в ООО «Стулья».
Получается, что если мы откроем форму платежного поручения в конце 2010 года, то увидим, что платеж был произведен в пользу компании, которая физически не существовала в 2009 году.
2) Допустим, в марте 2010 года произошло объединение ООО «Кровать» и ЗАО «Диваны», в результате появилось ОАО «Диваны и кровати».
Что могут сделать пользователи? А компанию ООО «Кровать» они могут переименовать в ОАО «Диваны и Кровати», а также могут переименовать ЗАО «Диваны» в «Диваны и Кровати».
Самое интересное начнется с самого первого отчета, когда выяснится, что все платежи между разными юридическими лицами (3 фактических и 4 в базе данных) перепутаны и отличить их могут только люди, производившие платежи (которые, к сожалению, , были уволены и не работают в вашей компании).
Конечно, все действия можно реконструировать по истории.
Этим будете заниматься только вы, а не сотрудники бухгалтерии (ну они не будут ковыряться во внутренностях вашей системы, ведь у них еще много бумажной работы, в которой нужно разобраться; и, в в конце концов, кто разработал систему? Ваш отдел? Ну, значит, ваша задача в целом - платить, а не разбираться с системами).
И всё это уже в корне неверно: а) вы берете на себя ответственность за те действия, на совершение которых вы вообще не имеете права; б) есть ситуации, которые в принципе невозможно понять; в) это очевидная ошибка в системе, возникновение которой вы не предусмотрели.
Итак, я пришел к тому, о чем хотел поговорить.
Проектирование объектов, связанных с документами.
Выдвинем несколько требований: 1. Все данные документа должны быть устойчивы к изменениям.
Это не означает, что если пользователь захочет изменить получателя платежа в платежном поручении, он не сможет этого сделать, но это означает, что если он переименует получателя платежа в справочнике юридических лиц, то будет отражено старое название.
в платежном поручении.
2. Документы должны поддерживать любую логику, описанную в бизнес-процессе.
В описанном примере это означает, что если вам необходимо просуммировать суммы всех платежных поручений по всем юридическим лицам, имеющим разные наименования, у вас будет техническая возможность это сделать.
Насколько мне позволяет мой опыт (привет системе мэрии Москвы), могу сказать, что первый пункт помнят почти все, а вот пункт 2 почти никто не помнит. Обычно это реализуется следующим образом: все поля документа (обычно все те поля, которые попадают в печатную форму документа) сохраняются в таблице базы данных, относящейся к этому документу, в текстовом виде.
В нашем примере это означает, что помимо ссылки на компанию в таблице хранится еще и название этой компании.
Это, конечно, устраняет часть проблем, но не все.
И вообще это идеологически неверно: ссылка сохраняется на компанию с одним названием, а в платежном поручении отображается другое название (это если компания была переименована).
Как мы решили эту проблему
Мы рассмотрели два варианта: 1. Все изменения сохраняются в справочнике юридических лиц.Те.
При обновлении данных в справочнике мы не только записываем историю изменений, но и физически не обновляем изменяемую строку — просто отмечаем ее как неактивную.
При этом создается новая строка с флагом «текущая запись».
В этом случае во вновь записываемой строке создается ссылка на родительскую запись, т.е.
на предыдущую версию этой строки.
Также при создании новой версии строки фиксируется время ее создания.
Таким образом, зная дату создания документа (на примере платежного поручения), мы всегда можем узнать, какие данные о контрагенте были актуальны на тот момент. Более того, поскольку наши версии записей имеют в таблице разные id, суммировать (группировать/классифицировать/делить) по ним одно удовольствие.
2. Справочник юридических лиц состоит из двух таблиц.
Первый содержит только те поля, которые характеризуют данную сущность, и называется основным.
Обычно это неизменяемые поля данной сущности (в примере с компаниями скорее всего подойдет пара ИНН и КПП).
Замечу, что вполне может быть, что таких полей будет ноль, т.е.
единственное неизменяемое поле в таблице — это id, и это абсолютно нормально.
Вторая содержит все поля этой сущности, а также ссылку на запись в родительской таблице и время создания новой записи.
Таким образом, все документы, относящиеся к данному юридическому лицу, будут хранить одну ссылку (на запись в основной таблице), но актуальная для данного документа версия легко восстанавливается по моменту создания документа и по «времени модификации».
столбец записи в подчиненной таблице справочника.
В результате был выбран второй вариант. И вот почему: 1. Общая ссылка на родительский элемент сохраняет все преимущества первого варианта (мы по-прежнему можем легко разделить все варианты входа на их временные модификации и работать с каждым отдельно), но работа со всеми версиями родительской записи не вызывает любые трудности.
2. MS SQL: так как в первом случае следующая модификация ссылается на предыдущую (т.е.
NULL < - ver1 < - ver2 < - ver3 < - .
< - verN), then а) чтобы просмотреть всю историю изменений, нам придется обойти цепочку от i-го узла влево и вправо, что потребует некоторых затрат на уровне базы данных.
И это атомарная функция, которая просто возвращает информацию об изменениях записей.
б) невозможно будет использовать кластеризацию по версиям (во втором случае очень удобно привязывать индекс к ссылке на запись в родительской таблице).
Таким образом, мы можем очень дешево (с точки зрения базы данных) и быстро получить информацию обо всех изменениях записи.
3. Второй вариант позволяет очень просто запретить изменение данных, содержащихся в основной таблице, на уровне базы данных.
Таким образом, если попытка их изменения не увенчается успехом, пользователь как минимум подумает о правильном способе решения своей проблемы (в крайнем случае, обратится к человеку, сопровождающему программу).
Думаю, на вторую часть хватит. Я буду рад ответить на все ваши вопросы.
Теги: #развитие #ошибки #Чулан #финансовые системы #справочники
-
Скайп Снова Не Работает
19 Oct, 24
