vdimas wrote:
> КП>IT wrote:
>>>Весьма распространённое и в то же время ошибочное мнение, которым обычно прикрывается либо кривой дизайн базы либо объектной модели. В процессе разработки модель данных и структура базы могу и должны соответствовать друг другу. Вот ты мне можешь привести живой хороший пример, когда различия в структуре базы и модели заложены в дизайне? Примеров замазывания дыр полно, но мне бы хотелось увидеть именно правильное решение, не by кривой design, а by прямой.
> КП>ну например не будешь же ты связь БД много-на-много через промежуточную
> КП>сущность отображать отдельным объектом? Не будешь.
> Буду, и отображаю
> ManyToManyLink у нас называется, объект заточен на предоставление сервисов выборки связанных объектов.
Ну, это вопрос реализации. Я бы, например, завел симметричные коллекции
у связанных объектов, аналогично как для связей 1:N частенько заводится
с одной стороны коллекция, а с другой — свойство (типа
заказ-коллекция_пунктов, пункт-заказ). Вот внутри — ради бога, пользуйся
чем угодно. Но в домене это понятие отсутствует, посему не надое его
навязывать.

> КП>Допустим, для оптимизации каких-нибудь отчетов ты денормализуешь схему,
> КП>что, и модель так же денормализовывать? Нет. Естественно, они будут
> КП>похожи, но не всегда один в один: представь, что ты уже имеешь чужую
> КП>базу и тебе надо на ней что-то построить. Я не думаю, что твоя модель
> КП>предметной области будет идентична наследию, ей богу
>
> "Чужая база" — это действительно совершенно отдельный вопрос. Замечание IT насчет дыр и замазываний как раз лучше всего относится к такому случаю. Универсального решения этой проблемы нет. Решение надо вырабатывать на месте с учетом большого количества параметров (в общем случае).

С тем, что это отдельный вопрос я нисколько не спорю. Надеюсь, с
утверждением о денормализации то ты согласен? Но по большому счету, если
уж тебе и надо вырасти на чужой базе, то скорее всего ты сделаешь
удобную себе модель, нежели создашь полное отображение того, что есть.
База данных — это средство хранения и получения информации. То, как ты
представляешь ее для работы приложения ну никак не обязано
соответствовать тому, как все это хранится. Типичный пример. Пусть есть
пара сущностей, между которыми есть логическая связь 1:N, но она
инициализируется крайне редко. Чтобы не расходовать место (в том числе в
индексах) вводится промежуточная сущность — связь (типа как для N:N,
только с некоторыми ограничениями, чтобы она работала только как 1:N).
Что, для нее тоже сущность заводить? Так это не соответствует модели
предметной области! Там не коллекция вторых сущностей, тем более не
странный ManyToManyLink, а именно ссылка одной сущности на другую. А как
это в БД — дело десятое.
Я могу согласиться в отношении соответствия с вами только в одном: на
начальных этапах разработки модель данных соответствует модели
предметной области, так уж процесс устроен, что сначала анализируется
домен (с его моделированием, результаты которого вырастают в модель
предметной области), а потом проектируется база. Но никак не наоборот.
Далее, по мере детализации проектирования, разработки и тем более
поддержки и развития эти модели расходятся.