Вопрос по database – отношение один ко многим в базе данных - концепция дизайна

8

Отношение один ко многим между двумя таблицами должно быть реализовано с двумя или тремя таблицами? Например, мы должны иметь:

<code>author(id,otherAttributtes)
books(id,authorid,otherAttributes)
</code>

или же

<code> author(id,otherAttributtes)
    books(id,otherAttributes)
    authorConnectsBooks(authorid,booksid)
</code>

Мне больше нравится первый подход, но я видел второй и более сложные приложения много раз. Есть ли какой-либо недостаток для первого метода, или это просто личное, каким путем следовать?

спасибо за ответы !! (пример был случайным, я просто хотел показать отношения один ко многим) user666

Ваш Ответ

5   ответов
4

Но отношения, которые вы предлагаете в своем примере (между авторами и книгами), не один ко многим, а ко многим.

& quot; Автор может написать много книг, а книгу может написать один или несколько авторов. & quot;

И отношение «многие ко многим» должно быть реализовано с помощью 3 таблиц.

Хорошего дня.

5

второй много ко многим.

Authors
1 Larry Niven
2 Jerry Pournelle

Books
1 Integral Trees
2 King David's Spaceship
3 The Mote in God's eye

AuthorsBooks
1 1
2 2
1 3
2 3
1

нет необходимости в связующей таблице (authorConnectsBooks в твоем примере). Однако в вашем примере вы не имеете отношения один ко многим, поскольку один автор может написать много книг, а одна книга может быть написана многими авторами. В вашем примере вы на самом деле имеете отношения многие ко многим. Если у вас действительно есть отношение «многие ко многим», вам нужна таблица ссылок (authorConnectsBooks в твоем примере).

0

первое - это отношения один ко многим, в которых вам не нужна дополнительная таблица. Только две таблицы должны работать. Но во втором случае, поскольку это много-многозначное взаимодействие, вам потребуется добавить дополнительную таблицу, известную как Junction или таблицу перекрестных ссылок, поскольку большинство систем управления базами данных поддерживают только отношения «один ко многим», это необходимо реализовать такие отношения вручную через третью соединительную таблицу. Первичный ключ соединительной таблицы обычно формируется с использованием первичных ключей таблиц, которые он соединяет. Вот вики-страница, которая объясняет тот же самый пример, который вы просили:

ССЫЛКА НА САЙТ

23

а второй показывает отношение многие ко многим.

Пример скажем, мы используем первый пример

Author
AuthorID

Book
BookID
AuthorID

Как бы вы представили, что Джейн и Джон написали книгу «Stackoverflow для удовольствия»? В этой таблице отношений вы не можете, вы заявили, что один автор может написать много книг. Так что либо Джейн написала это, либо Джон написал это. Если бы только один из них написал книги, вы могли бы использовать этот тип отношений. Однако, если вы хотите показать, что оба написали эту книгу, вам понадобятся отношения многие ко многим.

Теперь, используя ту же аналогию с Джейн и Джоном, вы можете представить обоих авторов в одной книге, используя второй пример - отношения «многие ко многим».

Давайте используем Stackoverflow в качестве примера, начиная с отношения один ко многим и заканчивая отношением многие ко многим:

Authors
Joel
Jeff

Books
Stackoverflow Joel

Бедный Джефф, ему не приписывают stackoverflow из приведенного выше примера ... поэтому нам нужно это исправить:

Author
Joel
Jeff

Books
Stackoverflow

AuthorBooks
Stackoverflow Jeff
Stackoverflow Joel

Теперь все счастливы ...

Нам придется удалить запись, в которой Джефф является владельцем, поскольку он больше не является :-(

Похожие вопросы