На всякий случай подытожу — вдруг в будущем эту статью будут читать студенты, надо их предостеречь :) — и больше уже возвращаться не буду.
В нотации crow foot значки и имеют разный смысл, так же, как и и , и в статье много неверных схем в том смысле, что они не соответствуют тексту, например, в тексте речь идёт про обязательность, а на схеме этот конец связи с "ноликом".
В зависимости от потребностей можно выбирать один из правильных вариантов, например, при связи "1:1" хранить всё в одной таблице или в двух связанных.
Какие потребности могут заставить выбрать неправильный вариант, я не представляю.
Делают это для того, чтобы не раздувать таблицу, а также когда например хотят разделить те поля, которые не у всех заполняются (напр, детали сущности).
Как раз при правильной структуре будет меньше полей за счёт того, что связь будет одна.
сложно, но можно.
Если что-то может пойти не так — оно обязательно пойдёт не так.
На предыдущем проекте наелись вот этого самого. В структуре БД не был предусмотрен (нашими предками) контроль консистентности, в результате багов (и ещё неправильных подходов к разработке) накопилось такое огромное количество "мусорных" данных, что решение этой проблемы заняло сотни человеко-часов.
Задавать связь мощности "1:1" через две связи между таблицами нельзя. Тем самым Вы открываете дорогу для возникновения неконсистентного состояния системы.
Пример:
В таблице Citizen есть запись с CitizenID == 42 и PassportID == 999 (пусть это будет некто Иванов).
В таблице PassportData есть запись с PassportID == 999 и CitizenID == 123 (это айдишник Петрова).
Вопрос: кому принадлежит паспорт с айдишником 999 — Иванову или Петрову?
Такое ощущение, что Вы плохо понимаете нотацию crow foot. Есть куча мест, где по тексту связь обязательна, а на схеме — необязательна.
Пример: п.2.1, цитирую: "У каждого родителя есть как минимум один ребенок.". При этом на схеме у таблицы Child значок "от 0 до N", т.е. детей у родителя может и не быть.
В п.2.2, где наличие детей становится необязательным, Вы почему-то сделали необязательным наличие родителя — со стороны таблицы Person изображена мощность "0 или 1".
Ещё пример — 1.1.2. По Вашей схеме у гражданина наличие паспорта необязательно, как и наличие у паспорта гражданина.
И т.д.
Вот Вы привели кратко теорию по DDD — а зачем? При проектировании Вашей системы вы DDD не использовали — я делаю этот вывод на том основании, что при описании процесса проектирования ни разу не были упомянуты ни единый язык, ни ограниченный контекст, ни остальные термины из DDD.
Термин "анемичная модель" встречается в посте один раз — в заголовке. Те, кто знает, что это такое — видят, что в системе именно она и используется. Для тех же, кто не знает, было бы неплохо привести определение и показать, что Ваша система под него подпадает.
Он может и не знать, что результат, который он считает ошибочным — может быть на самом деле верным
Это как вообще? У Вас программисты лепят фичи без спецификации, от ветра головы своея?
При возникновении требования аналитик формализует его в виде спецификации.
Программист в соответствии с этой спецификацией лепит фичу.
Тестировщик проверяет, что творение программиста этой спецификации соответствует. Если видит несоответствие — заводит багу. Аналитик (да, Вы правы, именно он видит общую картину) для этой баги выставляет приоритет и определяет срочность (эта/следующая итерация, бэклог и т.д.)
Аналитик не может без тестировщика завести багу, ну никак. Тестировщик без аналитика — может. Так зачем задействовать двоих там, где можно обойтись одним?
А если ещё не зарелизили?
Программист запилил фичу, перед попаданием на прод она, естественно, проходит разные этапы проверки, в том числе тестировщиком.
Тестировщик обнаружил баг (несоответствие поведения системы спецификации) — либо он может завести баг сразу сам, либо, по Вашей схеме, должен отвлекать аналитика только для того, чтобы тот под диктовку багу завёл?
Давайте и я добавлю про Ростелеком (простите, люди добрые, — кипит, не могу удержаться!).
Подключил их интернет (вынуждено), при работе в Личном кабинете полезли проблемы. Написал на их сайте два обращения в техподдержку — ответа так и не дождался! Вообще.
И это ещё не всё.
Проблему удалось прояснить (не решить, а только выяснить) другим путём.
Как оказалось, если вы хотите иметь N услуг от Ростелекома, вам нужно иметь N разных почтовых адресов. Занавес...
Ещё такой вопрос.
Единственный способ каталогизации заметок — это разделы, и заметка может находиться только в одном из них? Если да, то это плохо.
Допустим, у меня есть заметка по теме "Безопасность локальных сетей на основе Linux" и разделы "Информационная безопасность", "Локальные сети", "ОС Linux" — куда я должен её поместить?
В контексте организации информации иерархия — зло, теги — наше всё.
На всякий случай подытожу — вдруг в будущем эту статью будут читать студенты, надо их предостеречь :) — и больше уже возвращаться не буду.
и 
имеют разный смысл, так же, как и 
и 
, и в статье много неверных схем в том смысле, что они не соответствуют тексту, например, в тексте речь идёт про обязательность, а на схеме этот конец связи с "ноликом".
В нотации crow foot значки
В том-то и дело, что у Вас схема 2.1.2 выглядит так:
Именно это я и пытаюсь до Вас донести.
В зависимости от потребностей можно выбирать один из правильных вариантов, например, при связи "1:1" хранить всё в одной таблице или в двух связанных.
Какие потребности могут заставить выбрать неправильный вариант, я не представляю.
Не совсем понимаю, как проблема с несобираемыми данными связана с неправильной в данном конкретно случае структурой БД.
Нет, не правильно.
Если, как у Вас написано, "У каждого родителя есть как минимум один ребенок.", то связь должна выглядеть вот так:
Как раз при правильной структуре будет меньше полей за счёт того, что связь будет одна.
Если что-то может пойти не так — оно обязательно пойдёт не так.
На предыдущем проекте наелись вот этого самого. В структуре БД не был предусмотрен (нашими предками) контроль консистентности, в результате багов (и ещё неправильных подходов к разработке) накопилось такое огромное количество "мусорных" данных, что решение этой проблемы заняло сотни человеко-часов.
Задавать связь мощности "1:1" через две связи между таблицами нельзя. Тем самым Вы открываете дорогу для возникновения неконсистентного состояния системы.
Пример:
Вопрос: кому принадлежит паспорт с айдишником 999 — Иванову или Петрову?
Такое ощущение, что Вы плохо понимаете нотацию crow foot. Есть куча мест, где по тексту связь обязательна, а на схеме — необязательна.
Пример: п.2.1, цитирую: "У каждого родителя есть как минимум один ребенок.". При этом на схеме у таблицы Child значок "от 0 до N", т.е. детей у родителя может и не быть.
В п.2.2, где наличие детей становится необязательным, Вы почему-то сделали необязательным наличие родителя — со стороны таблицы Person изображена мощность "0 или 1".
Ещё пример — 1.1.2. По Вашей схеме у гражданина наличие паспорта необязательно, как и наличие у паспорта гражданина.
И т.д.
Это как вообще? У Вас программисты лепят фичи без спецификации, от ветра головы своея?
Аналитик не может без тестировщика завести багу, ну никак. Тестировщик без аналитика — может. Так зачем задействовать двоих там, где можно обойтись одним?
А если ещё не зарелизили?
Программист запилил фичу, перед попаданием на прод она, естественно, проходит разные этапы проверки, в том числе тестировщиком.
Тестировщик обнаружил баг (несоответствие поведения системы спецификации) — либо он может завести баг сразу сам, либо, по Вашей схеме, должен отвлекать аналитика только для того, чтобы тот под диктовку багу завёл?
Спасибо!
Регистрировался, но не удалось поучаствовать :(
Скажите, пожалуйста, видеозапись выкладывать где-нибудь будете?
Спасибо!
Подскажите, пожалуйста, почему к этому конкретно видео доступ закрыт, хотя все другие открыты?
Как граммар-наци насчёт слога не соглашусь. В моей точки зрения "неплохой слог" не может сочетаться с достаточно низкой грамотностью текста.
А запись не планируете выкладывать?
Давайте и я добавлю про Ростелеком (простите, люди добрые, — кипит, не могу удержаться!).
Подключил их интернет (вынуждено), при работе в Личном кабинете полезли проблемы. Написал на их сайте два обращения в техподдержку — ответа так и не дождался! Вообще.
И это ещё не всё.
Проблему удалось прояснить (не решить, а только выяснить) другим путём.
Как оказалось, если вы хотите иметь N услуг от Ростелекома, вам нужно иметь N разных почтовых адресов. Занавес...
Метки (это теги) можно выстраивать в иерархию любой глубины вложенности.
Ещё такой вопрос.
Единственный способ каталогизации заметок — это разделы, и заметка может находиться только в одном из них? Если да, то это плохо.
Допустим, у меня есть заметка по теме "Безопасность локальных сетей на основе Linux" и разделы "Информационная безопасность", "Локальные сети", "ОС Linux" — куда я должен её поместить?
В контексте организации информации иерархия — зло, теги — наше всё.