ссылко: "Я открыл гугл и набрал слова “математика развернуть стрелочки”. Ба! Википедия! Теория категорий и ко-алгебра! Теперь я точно знаю, что есть решение проблемы!"
>> Да, если использовать таблицу связей, куда ее поместить
Да никуда. Зачем Вы вообще приплели сюда "таблицы связей"? Вы реляционную модель пихаете в объектно-ориентированный подход и удивляетесь: Ба! Не подходит! Криво как-то! :) Я уже писал в своём блоге, это как взять гвоздодёр вместо отвётрки и по-детски искренне удивляться, до чего же неудобный инструмент для выкручивания болтов люди догадались придумать :) В объектной модели Вам не потребуются никаке "таблицы связи". Они существуют только потому, что парадигма RDBMS такая. У Вас и в коде нет никаких "коллекций связи", а есть объекты и отношения между ними. Я надеюсь. Если, конечно, Вы тупо не мапите таблицы БД в объекты один в один, что было бы смешно, конечно же и, не волнуйтесь, я Вас в этом не подозреваю :)
Есть объект "Book", у него есть коллекция авторов, есть коллекция оценок. Такой объект. Целый. С таким объектом мы работаем в коде. Такой объект мы берём с книжной полки. Целый, понимаете? И, в идеале... Я думаю, в подавляющем большинстве случаев, мы работаем с целыми объектами (ну, такова парадигма ОО-программирования) и очень хотим, чтобы БД могла "на тебе объект" и "дай-ка мне мой объект". И не задумываться о маппингах. Это мечта. Не "дай-ка мне три объекта, а я буду их связывать по ничего не значащим с точки зрения бизнес-модели ID" :) Сущность. Объект. Целый. Нормальный, а не "нормализованный". Это и быстрее, кстати: достать и дать одну сущность, а не джойнить нормализованое, возвращать денормализованый продукт джойнов, снова нормализовывать в коде в какой-то один объект и, не дай боже, не забыть включить туда ID всех "вложеных" членов, а то ой, кошмар какой настанет когда захотим сделать update :)
Да, для этого придуман ORM.
>> Ну вот уже лет 5 как есть Хибернейт, который позволяет объектно связывать коллекции, плюя на всякие ID.
Придуман. И не только он. Но на счёт "плюя" Вы, конечно, загнули. Если на них "честно" плевать, то Вы не сможете сделать update ;) Он на них не плюёт, а бережно хранит. Да, мы (индустрия) изобрели ORM. В некотором роде это костыль, согласитесь? Я в тезисах о выступлении Эрика это отметил: ORM позволяет нам "пофиксить обратно" тот простой объект, который в "сломанном" виде лежит в БД. Частично. Это всё да. Такой вот хак. Неплохой, хороший хак. А другого и нет. Однако, это сильно увеличивает уровень сложности. Привязывает нас к конкретной схеме и уже нельзя сказать "вот у этого кастомера в объекте пяток атрибутов, а у того - тока два". В ODBMS этого даже не надо говорить. Какой есть объект - ну, такой уж и есть, что есть - то и храним. Каждый клиент получит своё. Никаких "миграций данных" и alter table при добавлении новых свойств. Это - удобно. Часто удобно. Иногда - нет. Всему свои задачи. ORM заставляет нас поддерживать XML-портянки маппингов. Хорошо, в последнее время - не обязательно XML, уже как-то что-то можно и атрибутиками в коде задать. Та ещё задача, если вы что-то более-менее сложное делаете. Погуглите термин "impedance mismatch". Мы делаем охрененно много телодвижений для охрененно простой операции - сохранить объект и получить его обратно. Сложных телодвижений. Со сложными генерациями сложных сиквелов. Ещё раз, посмотрите на альтернативы RDBMS, просто, чтобы быть в курсе.
>>тем более что у таблицы книги всё равно нет возможности хранить список авторов, как и у автора список книг. Всегда используются таблицы связей.
Вы либо то, что я писал, читали невнимательно, либо издеваетесь надо мной. Именно это я и сказал в первой фразе о проблемах RDBMS - возможность хранить только скаляры. Ваше "всегды используются таблицы связей" имеет смысл только в "критикуемых" в данном случае RDBMS. В OODBMS, я бы сказал, "никогда не используются таблицы связей". Дуально Вашему "всегда" просто ;) Ну поймите Вы - парадигма другая. Вот и всё.
>>Да, если использовать таблицу связей, куда ее поместить при инверсии стрелок, к авторам или книгам - вопрос крайне неясный. В реляционной же модели такие выверты выглядят намного естественнее.
С последней фразой согласен. Действительно, в не-реляционной модели такие выверты выглядят дико. Компенсируется это тем, что они там не нужны. И Вы не станете там такого делать. Там и других вывертов хватает :)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2010-12-11 02:02 am (UTC)Да никуда. Зачем Вы вообще приплели сюда "таблицы связей"? Вы реляционную модель пихаете в объектно-ориентированный подход и удивляетесь: Ба! Не подходит! Криво как-то! :)
Я уже писал в своём блоге, это как взять гвоздодёр вместо отвётрки и по-детски искренне удивляться, до чего же неудобный инструмент для выкручивания болтов люди догадались придумать :)
В объектной модели Вам не потребуются никаке "таблицы связи". Они существуют только потому, что парадигма RDBMS такая. У Вас и в коде нет никаких "коллекций связи", а есть объекты и отношения между ними. Я надеюсь. Если, конечно, Вы тупо не мапите таблицы БД в объекты один в один, что было бы смешно, конечно же и, не волнуйтесь, я Вас в этом не подозреваю :)
Есть объект "Book", у него есть коллекция авторов, есть коллекция оценок. Такой объект. Целый. С таким объектом мы работаем в коде. Такой объект мы берём с книжной полки. Целый, понимаете?
И, в идеале... Я думаю, в подавляющем большинстве случаев, мы работаем с целыми объектами (ну, такова парадигма ОО-программирования) и очень хотим, чтобы БД могла "на тебе объект" и "дай-ка мне мой объект". И не задумываться о маппингах. Это мечта. Не "дай-ка мне три объекта, а я буду их связывать по ничего не значащим с точки зрения бизнес-модели ID" :) Сущность. Объект. Целый. Нормальный, а не "нормализованный". Это и быстрее, кстати: достать и дать одну сущность, а не джойнить нормализованое, возвращать денормализованый продукт джойнов, снова нормализовывать в коде в какой-то один объект и, не дай боже, не забыть включить туда ID всех "вложеных" членов, а то ой, кошмар какой настанет когда захотим сделать update :)
Да, для этого придуман ORM.
>> Ну вот уже лет 5 как есть Хибернейт, который позволяет объектно связывать коллекции, плюя на всякие ID.
Придуман. И не только он.
Но на счёт "плюя" Вы, конечно, загнули. Если на них "честно" плевать, то Вы не сможете сделать update ;) Он на них не плюёт, а бережно хранит.
Да, мы (индустрия) изобрели ORM. В некотором роде это костыль, согласитесь? Я в тезисах о выступлении Эрика это отметил: ORM позволяет нам "пофиксить обратно" тот простой объект, который в "сломанном" виде лежит в БД. Частично. Это всё да. Такой вот хак. Неплохой, хороший хак. А другого и нет.
Однако, это сильно увеличивает уровень сложности. Привязывает нас к конкретной схеме и уже нельзя сказать "вот у этого кастомера в объекте пяток атрибутов, а у того - тока два". В ODBMS этого даже не надо говорить. Какой есть объект - ну, такой уж и есть, что есть - то и храним. Каждый клиент получит своё. Никаких "миграций данных" и alter table при добавлении новых свойств. Это - удобно. Часто удобно. Иногда - нет. Всему свои задачи.
ORM заставляет нас поддерживать XML-портянки маппингов. Хорошо, в последнее время - не обязательно XML, уже как-то что-то можно и атрибутиками в коде задать. Та ещё задача, если вы что-то более-менее сложное делаете.
Погуглите термин "impedance mismatch".
Мы делаем охрененно много телодвижений для охрененно простой операции - сохранить объект и получить его обратно. Сложных телодвижений. Со сложными генерациями сложных сиквелов.
Ещё раз, посмотрите на альтернативы RDBMS, просто, чтобы быть в курсе.
>>тем более что у таблицы книги всё равно нет возможности хранить список авторов, как и у автора список книг. Всегда используются таблицы связей.
Вы либо то, что я писал, читали невнимательно, либо издеваетесь надо мной. Именно это я и сказал в первой фразе о проблемах RDBMS - возможность хранить только скаляры. Ваше "всегды используются таблицы связей" имеет смысл только в "критикуемых" в данном случае RDBMS. В OODBMS, я бы сказал, "никогда не используются таблицы связей". Дуально Вашему "всегда" просто ;)
Ну поймите Вы - парадигма другая. Вот и всё.
>>Да, если использовать таблицу связей, куда ее поместить при инверсии стрелок, к авторам или книгам - вопрос крайне неясный. В реляционной же модели такие выверты выглядят намного естественнее.
С последней фразой согласен. Действительно, в не-реляционной модели такие выверты выглядят дико. Компенсируется это тем, что они там не нужны. И Вы не станете там такого делать. Там и других вывертов хватает :)