Тут при разработке т.з. возникло такое отношение между сущностями. Не подскажите, в все ли тут в порядке с точки зрения архитектуры, или лучше еще поколдовать?
Здесь должен быть предметный разговор, потому что в реальном мире такое иногда случается и сам по себе факт наличия такого отношения ничего не значит. О каких сущностях идет речь?
Здравствуйте, Keneneler, Вы писали:
K>Тут при разработке т.з. возникло такое отношение между сущностями. Не подскажите, в все ли тут в порядке с точки зрения архитектуры, или лучше еще поколдовать?
Здравствуйте, Keneneler, Вы писали:
K>Тут при разработке т.з. возникло такое отношение между сущностями. Не подскажите, в все ли тут в порядке с точки зрения архитектуры, или лучше еще поколдовать?
Объясните, мне дремучему, что означает сей символ 1_* ?
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, Keneneler, Вы писали:
K>>Тут при разработке т.з. возникло такое отношение между сущностями. Не подскажите, в все ли тут в порядке с точки зрения архитектуры, или лучше еще поколдовать? A>Объясните, мне дремучему, что означает сей символ 1_* ?
A>СУВ, Aikin
1 и больше (хотя бы один). Ну, типа актёр снялся минимум в одном фильме, а в Фильме хотя бы один актёр принимал участие. Актёров с пустой фильмографией в базе быть не может, как и фильмов с пустым актёрским составом.
Здравствуйте, <Аноним>, Вы писали:
А>1 и больше (хотя бы один). Ну, типа актёр снялся минимум в одном фильме, а в Фильме хотя бы один актёр принимал участие. Актёров с пустой фильмографией в базе быть не может, как и фильмов с пустым актёрским составом.
Ага, ясно.
Т.е. это замечание
Здравствуйте, Keneneler, Вы писали:
K>Тут при разработке т.з. возникло такое отношение между сущностями. Не подскажите, в все ли тут в порядке с точки зрения архитектуры, или лучше еще поколдовать?
Я бы тут думал больше о пользователях. Удобно будет заставлять человека сразу заполнять 2 сущности? Возможно, тут уместнее многие-ко-многим, а проверку на 1_* убрать из базы и делать в критичных местах программы? Пусть себе база хранит неполные данные, а программа проверяет всё ли нужное ей дано для выполнения действия и, в случае чего, ругается. Всё равно в программе эти проверки делать.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Keneneler, Вы писали:
K>>Тут при разработке т.з. возникло такое отношение между сущностями. Не подскажите, в все ли тут в порядке с точки зрения архитектуры, или лучше еще поколдовать?
А>Я бы тут думал больше о пользователях. Удобно будет заставлять человека сразу заполнять 2 сущности? Возможно, тут уместнее многие-ко-многим, а проверку на 1_* убрать из базы и делать в критичных местах программы? Пусть себе база хранит неполные данные, а программа проверяет всё ли нужное ей дано для выполнения действия и, в случае чего, ругается. Всё равно в программе эти проверки делать.
Ну так пожелал заказчик, я обычно так не делал. Поэтому и спросил.
Здравствуйте, Aikin, Вы писали:
А>>1 и больше (хотя бы один). Ну, типа актёр снялся минимум в одном фильме, а в Фильме хотя бы один актёр принимал участие. Актёров с пустой фильмографией в базе быть не может, как и фильмов с пустым актёрским составом. A>Ага, ясно. A>Т.е. это замечание
Не то, чтобы "неверно", это мое мнение. Выбор между * и 1..* делает конечно проктировщик. Но именно в случае "актер-фильм" вряд ли кто-то (уж я точно) выберет 1..*. Ведь в этом случае актера можно добавить в базу только в одной транзакции с каким нибудь фильмом. Что явно не соответствует пользовательским сценариям.
Здравствуйте, wildwind, Вы писали:
W>Не то, чтобы "неверно", это мое мнение. Выбор между * и 1..* делает конечно проктировщик. Но именно в случае "актер-фильм" вряд ли кто-то (уж я точно) выберет 1..*. Ведь в этом случае актера можно добавить в базу только в одной транзакции с каким нибудь фильмом. Что явно не соответствует пользовательским сценариям.
Угу, это с точки зрения реализации так. С точки зрения бизнесс логики и сущностей связь 1..*
Дело в том, что как раз твое замечание заставило меня спросить что же это за зверь такой 1_*
Здравствуйте, Aikin, Вы писали:
A>Угу, это с точки зрения реализации так. С точки зрения бизнесс логики и сущностей связь 1..*
Вообще-то это должно быть одно и то же. Иначе это ошибка проектирования, на мой взгляд. Если конечно мы описываем не предметную область в целом, а отношения в конкретной БД.
И, если уж на то пошло, в жизни бывают и актеры без фильмов (выпускники института), и фильмы без актеров (документальные, анимационные).
