Бекграунд: Заказчик очень часто задает КАК сделать, что-то вместо, того чтобы формулировать ЧТО нужно сделать. В общем, это даже и не заказчик, а постановщик со стороны заказчика.
Проблема следующая. Создается, уже есть банковская система. Как обычно физические лица идентифицируются с помощью типа документа, номера документа (номер паспорта) и личного номера. Есть следующие типы документов: 1. "Паспорт гражданина РБ от 1996 года", 2. "Паспорт иностранного гражданина". Сейчас нужно работать с клиентами с типом документа "Вид на жительство" (3).
Постановщик выступает за то, чтобы совместить тип 1 и 3, и получить что-то вроде "Паспорт гражданина РБ от 1996 года или вид на жительство". Во "внутренностях" программы тип "паспорт гражданина РБ от 1996 года" так и остается типом документа "Паспорт гражданина РБ от 1996 года". С его точки зрения "совмещение" типов документов вполне правильный подход, т.к. позволяет ускорить разработку. Буквально произноситься следующее: пусть при вводе показывается сообщение, что это вид на жительство, ну а данные просто вводятся, т.е. типа документа пусть будет "Паспорт гражданина РБ от 1996 года", ну а личный номер и номер документа уже будет соответствовать виду на жительство. Постановщик убежден, что т.к. сейчас тип документа не используется, то "ничего страшного произойти не может".
Я аргументирую:
1. тип документа будет не верен, если реализовать такой ввод.
2. более чем вероятны ошибки в других системах и при взаимодействии с другими системами, т.к. как бы информация о типе документа есть, но она просто не верна, может интерпретироваться другими разработчиками не верно.
3. то, что сейчас тип документа не используется только говорит о том, что т.к. семантика не отражена в синтаксисе, то именно тип документа и работа с этими данными будет проблемными моментами в будущем коде.
4. сущность тип документа становиться через чур сложной, т.к. значения типа не определяют точно тип документа, а могут определять сразу два типа документа.
5. такая "экономия" на разработке может вылиться в то, что возможно могут возникать и проблемы с безопасностью банка, не уверен, но эти затраты могут на порядки перекрыть экономию при разработке.
Здравствуйте, klizardin, Вы писали:
K>Можете ли вы рассудить?
Вы правы, хоть чуть подкованные заказчики любят выражение "да сделайте просто: ...". Это просто почти всегда выливается потом в критичные ошибки дизайна, которые приходится переписывать полностью. Теперь у вас другой вопрос, как удержать заказчика от активного вмешательства во внутреннюю структуру данных, это уже в "Управление проектами".
Поддерживаю.
Дополню ответ Ziaw'a — не используйте естественные ключи в качестве внешних. Огребётесь.
[ОФФТОП, это уже в управление проектами]
Вот то что вам говорят как делать — это очень печально. Тут три варианта:
— полный игнор, делаем что надо;
— включаем дурку, требуем бабок за переделывание;
— мягко объясняем заказчику во что выльются его хотелки.
У всех вариантов — свои побочные эффекты, причём зависящие от психики заказчика. Главное, не начните метаться между вариантами поведения, любой опытный дрессировщик объяснит почему
[/ОФФТОП]
Если подходить формально, то есть сущность — человек/личность/human resource — кому как нравится. У человека может быть несколько идентификационных документов. А дальше извращайтесь с типами документов. Но это надо втыкать в предметную область. Вдруг у вас человек и идентифицированная личность — разные вещи.
То, что "сейчас тип документа не используется", в некотором роде симптоматично.
Вы можете себе представить ситуацию, когда нужно будеть дифференцировать физиков по их типу документа? (не путать со статусами "соотечественник", "иностранец", "беженец" и т.д.)
Я к тому что вообще "Тип документа" нужен?
Не хватило бы (в идеале) просто текстового описания (а еще лучше скана), что за документ был предоставлен?
Здравствуйте, klizardin, Вы писали:
K>Можете ли вы рассудить?
Расскажите как используются типы документов, возможно ли заботать с ними полиморфно?
Если нет, то вся "экономия" заключается в несоздании экранной формы, но это бредовая идея.
Если всетаки будет полиморфная работа с этими данными, то уже думать надо.
Здравствуйте, ylem, Вы писали:
Y>Я к тому что вообще "Тип документа" нужен? Y>Не хватило бы (в идеале) просто текстового описания (а еще лучше скана), что за документ был предоставлен?
В идеале сущность "человек" вообще ничего не должна знать о идентификационных документах. Потому что здесь связь 1-к-1, которая элементарно превращается в 1-ко-многим. Естественно, меняются ФЗ и нормализация летит к чертям. Так что нефиг дизайнить схему данных из соображений "как проще".
P.S.
Я кстати насмотрелся на последствия сваливания в одну сущность атрибутов из разных областей. В лучшем случае сведения о людях живут в кадрах, бд пользователей, в идентификационных документах... А чаще всё ещё хуже — в одной табличке живут ФИО, стаж, пароль и адреса ближайших родственников. Архитекторы, ёк
Убивало как люди умудрялись говорить умные слова, голосовать за слабую связность и городить таких монстров (никого из присутсвующих в виду не имею ).
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, klizardin, Вы писали:
K>>Можете ли вы рассудить? G>Расскажите как используются типы документов, возможно ли заботать с ними полиморфно? G>Если нет, то вся "экономия" заключается в несоздании экранной формы, но это бредовая идея. G>Если всетаки будет полиморфная работа с этими данными, то уже думать надо.
Тип документа определяет то,
1. какие данные для идентификации нужно запрашивать у клиента/какие данные должен клиент предоставить.
2. Так же возможно то, какие услуги доступны для клиента с данным типом документа (хотя скорее всего это на будущее).
3. задает правила проверки ошибок при вводе операционистом данных о клиенте, когда клиент обращается за услугами, регистрируется для работы с сервисами.
т.е полиморфизм да, присутствует
1. на этапе ввода данных
2. на этапе представления данных о клиенте в другие подсистемы.
3. на этапе работы с клиентом.
тип документа входит в понятие идентификационные данные клиента.
G>Если нет, то вся "экономия" заключается в несоздании экранной формы
Здравствуйте, klizardin, Вы писали:
K>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, klizardin, Вы писали:
K>>>Можете ли вы рассудить? G>>Расскажите как используются типы документов, возможно ли заботать с ними полиморфно? G>>Если нет, то вся "экономия" заключается в несоздании экранной формы, но это бредовая идея. G>>Если всетаки будет полиморфная работа с этими данными, то уже думать надо.
K>Тип документа определяет то, K>1. какие данные для идентификации нужно запрашивать у клиента/какие данные должен клиент предоставить. K>2. Так же возможно то, какие услуги доступны для клиента с данным типом документа (хотя скорее всего это на будущее). K>3. задает правила проверки ошибок при вводе операционистом данных о клиенте, когда клиент обращается за услугами, регистрируется для работы с сервисами.
По есть тип документа никак не влияет на дальнейшую работу системы?
Тогда постановщик задач в чем-то прав.
K>т.е полиморфизм да, присутствует K>1. на этапе ввода данных K>2. на этапе представления данных о клиенте в другие подсистемы. K>3. на этапе работы с клиентом.
Если тип документа не влияет на другие операции, то не пристуствует.
CRUD для самого типа документа нет смыслка рассматривать.
K>тип документа входит в понятие идентификационные данные клиента.
Можно вообще не различать типы документов, а сделать несколько полей для каждого типа, часть которых вполне может быть незаполнена.
G>>Если нет, то вся "экономия" заключается в несоздании экранной формы K>какая экранная форма имеется в виду?
Форма ввода данных.
А у вас один человек не может обладать несколькими документами?
Как быть с несовершеннолетними/иностранцами/свидетельствами об утере паспорта etc?
Как насчёт смены паспортов?
Как насчёт офицерских военных удостоверений (они признаются наравне с паспортами, если за 5 лет ничего не менялось).
С удостоверениями МВД/прочими?
Это я ещё не разошёлся
Идентификация по документам — это такая штука, что её либо не делать вообще, либо делать с усердным изучением предмета. А то вам щас насоветуют
P.S. Если эта штука будет внедряться в бюджетной организации — будьте готовы к напрягу с персональными данными.
P.P.S. Кодить не разобравшись в предметной области — крайне дурной тон, отучайтесь
Здравствуйте, klizardin, Вы писали:
K>Можете ли вы рассудить?
Постом выше Sinix совершенно прав. Идентификация по документам должна начинаться с вдумчивого анализа. Если постановщик на анализ забил, он некомпетентен. Не знаю, как в РБ, а в РФ чуть ли не десяток документов, удостоверяющих личность, включая справку об освобождении, паспорт моряка, дипломатический паспорт и прочую экзотику, вроде нотариально заверенной копии паспорта или документов устанавливающих попечительство вместе с паспортом попечителя.
Против упрощения архитектуры есть один хороший аргумент. Модель данных, которую ты сейчас создаешь, проживет, при хорошем раскладе, десятки лет. Представь себе, прошло 25 лет, у тебя уже вырос сын, закончил школу, пошел работать программистом в банк, а там твоя модель все еще живет. И вот он возвращается в первый день с работы и спрашивает: "Папа, а какого, собственно, хрена ты такое угребие сотворил?" Неприятно получится. Поэтому, ИМХО, в вопросах, касающихся модели данных подобного рода упрощения недопустимы. Потом самим же хуже будет. И это навсегда, потому что легко менять модель, когда данных немного. Когда система пойдет в эксплуатацию, менять модель станет практически невозможно. Накопятся мегабайты данных, появятся неоднозначности, на схему данных завяжутся сторонние решения и т.п.
Вообще, время жизни это хороший индикатор, стоит ли тратить время на архитектуру и если стоит то сколько. Не единственный, конечно. Подробнее про него я писал у себя в блоге.
Здравствуйте, gandjustas, Вы писали:
G>Или будет ниому не нужна. G>Городить модель данных ради модели данных самое идиотское занятие.
Или будет никому не нужна. Нельзя сказать заранее, потому имеет смысл делать as best as you can. Модель данных, она ведь не для себя в вакууме делается, а для остального кода. Будет хреновая модель, будут проблемы с остальным кодом.
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Или будет ниому не нужна. G>>Городить модель данных ради модели данных самое идиотское занятие.
M>Или будет никому не нужна. Нельзя сказать заранее, потому имеет смысл делать as best as you can.
Зараннее сказать моно, для этого надо заниматься анализом требований.
Любая модель данных дополняет результаты анализа требований, а не является первичной.
M>Модель данных, она ведь не для себя в вакууме делается, а для остального кода. Будет хреновая модель, будут проблемы с остальным кодом.
Естественно, только хреновость модели данных зависит от очень многих факторов.
Здравствуйте, gandjustas, Вы писали:
G>Зараннее сказать моно, для этого надо заниматься анализом требований. G>Любая модель данных дополняет результаты анализа требований, а не является первичной.
Требования имеют свойство меняться. Тем более за десятки лет. Например, сейчас у топикстартера поведение системы никак не зависит от типа документа. Завтра выйдет новая разнарядка местного ФСБ о борьбе с терроризмом и тип документа неожиданно станет важным. Послезавтра какой-нибудь аналитик придумает новый алгоритм скорринга и вдруг потребуется отличать старые и новые паспорта. Через три месяца запретят хранить в базе сканы документов. Через год введут новый документ, удостоверяющий личность, у которого номер будет вычисляться из прочих данных и этот номер потребуется проверять. Потом кто-то захочет, чтобы система корректно обрабатывала смену фамилии, сохраняя историю. Этих требований еще нет, как предлагается их анализировать?
Здравствуйте, Miroff, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Зараннее сказать моно, для этого надо заниматься анализом требований. G>>Любая модель данных дополняет результаты анализа требований, а не является первичной.
M>Требования имеют свойство меняться. Тем более за десятки лет. Например, сейчас у топикстартера поведение системы никак не зависит от типа документа. Завтра выйдет новая разнарядка местного ФСБ о борьбе с терроризмом и тип документа неожиданно станет важным.
Важным для чего? Как изменится функционал системы?
Если действительно станет важно в тот момент и стоит заниматься созданием более подходящей модели данных.
M>Послезавтра какой-нибудь аналитик придумает новый алгоритм скорринга и вдруг потребуется отличать старые и новые паспорта. Через три месяца запретят хранить в базе сканы документов. Через год введут новый документ, удостоверяющий личность, у которого номер будет вычисляться из прочих данных и этот номер потребуется проверять. Потом кто-то захочет, чтобы система корректно обрабатывала смену фамилии, сохраняя историю. Этих требований еще нет, как предлагается их анализировать?
Это не требования, это совершенно внешние факторы, которые могут вообще никак не повлиять на функционал.
Если изменения функционала, вызванные желанием заказчика еще можно хоть как-то предугадывать, то такие неожиданности — вообще никак.
Поэтому все равно надо вносить изменения, в том числе и в модель данных. Остается только вопрос стоимости таких изменений.
А стоимость обычно пропорциональна объему того что уже есть. Поэтому чем меньше заранее создаешь, в том числе в плане модели данных, тем лучше.
Здравствуйте, gandjustas, Вы писали:
G>Важным для чего? Как изменится функционал системы? G>Если действительно станет важно в тот момент и стоит заниматься созданием более подходящей модели данных.
У топикстартера как раз наступил момент, когда требуется изменение функционала. Следует изменить архитектуру (может быть только модель) так, чтобы последующие добавления новых типов документов не становились проблемой. Пытаться сделать костыль в виде: вид на жительство будет неотличим системой от паспорта, так как это пока не требуется, большая ошибка.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, gandjustas, Вы писали:
G>>Важным для чего? Как изменится функционал системы? G>>Если действительно станет важно в тот момент и стоит заниматься созданием более подходящей модели данных.
Z>У топикстартера как раз наступил момент, когда требуется изменение функционала. Следует изменить архитектуру (может быть только модель) так, чтобы последующие добавления новых типов документов не становились проблемой. Пытаться сделать костыль в виде: вид на жительство будет неотличим системой от паспорта, так как это пока не требуется, большая ошибка.
В том то и дело что топикстартер не привел функционала, который обрабатывает разные типы документов (ну кроме ввода), поэтому до сих пор остается непонятным зачем городить что-то, кроме самого простого вариант — создать дополнительные поля в записи о клиене.
Даже сценарий, когда в зависимости от типа документа клиенту доступны разные услуги, отлично реализуется с такой схемой данных.
Здравствуйте, gandjustas, Вы писали:
G>В том то и дело что топикстартер не привел функционала, который обрабатывает разные типы документов (ну кроме ввода), поэтому до сих пор остается непонятным зачем городить что-то, кроме самого простого вариант — создать дополнительные поля в записи о клиене.
G>Даже сценарий, когда в зависимости от типа документа клиенту доступны разные услуги, отлично реализуется с такой схемой данных.
Постановщик выступает за то, чтобы совместить тип 1 и 3, и получить что-то вроде "Паспорт гражданина РБ от 1996 года или вид на жительство". Во "внутренностях" программы тип "паспорт гражданина РБ от 1996 года" так и остается типом документа "Паспорт гражданина РБ от 1996 года".
Я понял это так, что данные будут храниться в том же месте, что и паспорт. Т.е. система будет не в состоянии отличить паспорт от вида на жительство.
