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

вы-же сами написали "Если же ничего кроме реквизитов УЛ мне не надо, то достаточно просто текстового поля, где будет писаться наименование органа, выдавшего УЛ, в точном соответствии с тем, как оно написано в самом УЛ" . Почему-же если мне нужны только аттрибуты паспорта, то вписывать его в таблицу владельца неправильно ?
На самом деле хочу сказать, что вы с MasterZiv'ом меня безусловно убедили в необходимости выноса сущностей, спасибо вам, просто есть пара моментов, которые не дают спокойно спать. Если отделение милиции мне как таковое не нужно и его можно оставлять в таблице с паспортом, то почему если не нужен паспорт как таковой, то его нельзя оставить в таблице с владельцем ? Так, на всякий случай ? Только из-за пресловутой гибкости системы ?

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

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

474
Я про это и писал. Рад, что стало понятно.

у вас интересная манера вести разговор - вы сами придумали изначально отсутствующее требование про ведение истории и строите на ней все ваши выводы. По сути, это вообще не относиться к разговору, ибо даже если-бы паспорт у меня был вынесен, то никакой истории изменений все равно-бы не велось и ваши примеры про Петрову/Иванову все-равно были-бы совершенно нерелевантны.

474
Запись о получении аванса в системе - это отражение факта в реальном мире. Если одному и тому-же человеку выдали аванс дважды, что запрещено правилами - отрывать голову надо тому, кто выдал. Почему ему - потому что правила пишутся для людей, а не для компьютеров.

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

тогда спрошу по-другому: хорошо, в системе это один человек, реализовано правило о невыдаче аванса дважды - все замечательно.
По вашим словам "Вы в жизни себе представляете хоть один бумажный отчет в котором вместо ФИО - табельные номера?" в бумажных документах и на экране компьютера вашей системы человек идентифицируется ФИО + паспорт (внутри системы может быть также или введен суррогатный ключ). Кроме того, ФИО и паспорт показываються в соответствии с историей - если в апреле Иванова была Петровой, то на экране за апрель светиться именно Петрова. (кстати вы откуда вообще взяли такую дурацкую постановку задачи ? Никого не интересует, какое ФИО у нее было в апреле, если это не отделение милиции. И табельные номера с номерами клиентов к клиниках введены вовсе не для того, чтобы реализовывать такие требования - просто встречаются абсолютные тезки, и в отчетах для различения их пришлось-бы вбивать номера паспортов).
Все верно, я ничего вам не приписал ?
Так вот, бухгалтер хочет выдать аванс Ивановой (паспорт 45 3456), но система говорит, что этот человек уже получал аванс в этом месяце. Бухгалтер запрашивает отчет об авансах за этот месяц и конечно никакой Ивановой (паспорт 45 3456) там не находит, ибо она там еще была Петровой (паспорт 66 7890). Что теперь должна делать бухгалтер и кому будем отрывать голову ?

474
Я думал, что очевидным является, что реквизиты банков также меняются, как и атрибуты любых иных объектов. Извиняюсь, что не объяснил. Приведу пример тогда.

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

вы-уж все-таки определитесь, какой пример имеете ввиду, а то сначала говорите про авансы и бухгалтершу, а потом в качестве примера нужности ведения истории рассказываете про реквизиты платежки =)

474
Отрывать программисту или аналитику (смотря кто писал ТЗ). Иными словами - если система в информационных сообщениях связанных с объектами, показывает пользователю только изменяемые атрибуты объектов - это ошибка реализации, пусть и не критическая. Наличие в системе таких сообщений потенциально увеличивает операционные риски при работе с системой.

Насчет дурацких требований.. Навскидку могу предположить, что кроме милиции (кстати, а что это за милиция? миграционная служба, например, - это милиция или нет?), в хранении изменяемых ФИО граждан заинтересованы как минимум средние и высшие учебные заведения, загсы, банки, страховые компании, налоговые органы (а из-за этого почти все налоговые агенты), службы ЖКХ, операторы фиксированной связи, и еще множество организаций, которые лень перечислять, если честно.

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


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

так ведь паспорт у меня не в одном текстовом поле, а нескольких полях таблицы владельца

Сергей Васкецов
hey
Если отделение милиции мне как таковое не нужно и его можно оставлять в таблице с паспортом, то почему если не нужен паспорт как таковой, то его нельзя оставить в таблице с владельцем ? Так, на всякий случай ? Только из-за пресловутой гибкости системы ?

У одного документа УЛ орган, выдавший этот документ, один, и не меняется в течение времени жизни документа. С отношением человек-паспорт все по другому.

;) так все-таки почему этот самый паспорт, хоть он и меняется на протяжении жизни, нужно выделять ? Историю паспортов вести согласно бизнес-правилам не надо, нескольких паспортов тоже нету. Ну никак не возьму в толк - отделение милиции оставляем, а паспорт все равно выносим, хотя они с точки зрения логики одинакого достойны выноса/оставления

Сергей Васкецов
Сделаю еще одно поле со ссылкой на регион проживания. Адрес любой регистрации (в паспорте или на отдельном бланке, о чем Вы, видимо, позабыли) - это исключительно атрибут документа (а не человека). При изменении наименования региона адрес проживания для целей такой аналитики, как Вы описали выше, должен измениться, а адрес, указанный в документе - не должен. То есть, подобные адреса - это разные сущности. Другой вопрос, что заполнить такую ссылку можно в первом приближении на основании информации из текстового адреса (то есть запросы типа update ... from ... where ... like ...). Если же требование знать откуда физик - на уровне пожелания, то подойдет простейший like, с большой вероятностью этого будет достаточно для ответа на вопрос вида "а много ли у нас иногородних"? То есть, реализация зависит от цели, зачем это надо, насколько строгий учет необходим.

а зачем нам считать, что если вынести регионы (и заодно улицы и дома), то они прекращают быть аттрибутами паспорта ? Если регион (город, улица) изменился, то мы его просто не будем менять, раз это аттрибут паспорта.
Like по очевидным причинам будет давать не самые точные результаты (да еще и не самые быстрые), а приделав дополнительные столбцы вы получается просто дублируете прописку (и множите потенциальные ошибки ввода).
Ведь вообще-то вопрос "а сколько у нас иногородних" или "сколько человек живет в этой части города" вовсе не означает, что ответ должен непременно содержать новое название улицы (или города итп), которое ей дали вчера. Да и кто будет поддерживать согласованное состояние такой информации ? Это-же по-сути никому не нужно, и даже более того, имхо куда очевиднее для пользователей ожидать от системы ответа, базирующегося именно на прописке, а не на реальном положении вещей.
Возможно есть какие-то исключения (какая-нибудь милиция или налоговики, хотя и то сомнительно), но для обычных бизнес-процессов это имхо не нужно совершенно точно.