ссылко: "Я открыл гугл и набрал слова “математика развернуть стрелочки”. Ба! Википедия! Теория категорий и ко-алгебра! Теперь я точно знаю, что есть решение проблемы!"
А почему именно такой объект? Отношение-то M:N, можно и обратно.
> Таким образом, заявил Эрик, из моего простого объекта получилось вдруг три новых, в которые добавились какие-то новые сущности (идентификаторы), не имеющие к реальному объекту никакого отношения
Вообще-то авторы могут быть общими у разных книг. Более того, могут быть авторы и без книг. Для отчётов авторов надо как-то идентифицировать. Можно, конечно, по имени в паспорте. Но тогда всё равно надо тягать с этим ID все данные по авторам. Он что, предлагает дублировать + обновлять данные автора у всех книг? или что?
> плюс нужно писать дополнительный код, осуществляющий трансформацию
Ну вот уже лет 5 как есть Хибернейт, который позволяет объектно связывать коллекции, плюя на всякие ID.
> В результирующем “реляционном” подходе наоборот - потомок всегда знает о том, кто его родитель.
Бред. Авторы и книги -- кто чей предок и потомок? И прекрасно обходятся без прямых ссылок на себя, тем более что у таблицы книги всё равно нет возможности хранить список авторов, как и у автора список книг. Всегда используются таблицы связей. И 1:N тоже можно сделать так.
Да, если использовать таблицу связей, куда ее поместить при инверсии стрелок, к авторам или книгам - вопрос крайне неясный. В реляционной же модели такие выверты выглядят намного естественнее. C 1:N и двумя таблицами все проще.
Для книг будут существовать стрелки "автор книги", для автора - "книги автора". Раз мы говорим о стрелках, мне кажется неправильным выделять какое-то их направление отдельно, если мы говорим о внешнем представлении, а не о хранении. Внутри пусть хранят как им самим удобнее, главное - что мы видим снаружи.
![[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
В недоумении....
Date: 2010-12-09 10:46 am (UTC)> Таким образом, заявил Эрик, из моего простого объекта получилось вдруг три новых, в которые добавились какие-то новые сущности (идентификаторы), не имеющие к реальному объекту никакого отношения
Вообще-то авторы могут быть общими у разных книг. Более того, могут быть авторы и без книг.
Для отчётов авторов надо как-то идентифицировать. Можно, конечно, по имени в паспорте. Но тогда всё равно надо тягать с этим ID все данные по авторам. Он что, предлагает дублировать + обновлять данные автора у всех книг? или что?
> плюс нужно писать дополнительный код, осуществляющий трансформацию
Ну вот уже лет 5 как есть Хибернейт, который позволяет объектно связывать коллекции, плюя на всякие ID.
> В результирующем “реляционном” подходе наоборот - потомок всегда знает о том, кто его родитель.
Бред. Авторы и книги -- кто чей предок и потомок? И прекрасно обходятся без прямых ссылок на себя, тем более что у таблицы книги всё равно нет возможности хранить список авторов, как и у автора список книг. Всегда используются таблицы связей. И 1:N тоже можно сделать так.
Re: В недоумении....
Date: 2010-12-09 10:54 am (UTC)C 1:N и двумя таблицами все проще.
Re: В недоумении....
Date: 2010-12-09 12:52 pm (UTC)Раз мы говорим о стрелках, мне кажется неправильным выделять какое-то их направление отдельно, если мы говорим о внешнем представлении, а не о хранении.
Внутри пусть хранят как им самим удобнее, главное - что мы видим снаружи.