Вопрос по database – отношение один ко многим в базе данных - концепция дизайна
Отношение один ко многим между двумя таблицами должно быть реализовано с двумя или тремя таблицами? Например, мы должны иметь:
<code>author(id,otherAttributtes) books(id,authorid,otherAttributes) </code>
или же
<code> author(id,otherAttributtes)
books(id,otherAttributes)
authorConnectsBooks(authorid,booksid)
</code>
Мне больше нравится первый подход, но я видел второй и более сложные приложения много раз. Есть ли какой-либо недостаток для первого метода, или это просто личное, каким путем следовать?
Но отношения, которые вы предлагаете в своем примере (между авторами и книгами), не один ко многим, а ко многим.
& quot; Автор может написать много книг, а книгу может написать один или несколько авторов. & quot;
И отношение «многие ко многим» должно быть реализовано с помощью 3 таблиц.
Хорошего дня.
нет необходимости в связующей таблице (authorConnectsBooks в твоем примере). Однако в вашем примере вы не имеете отношения один ко многим, поскольку один автор может написать много книг, а одна книга может быть написана многими авторами. В вашем примере вы на самом деле имеете отношения многие ко многим. Если у вас действительно есть отношение «многие ко многим», вам нужна таблица ссылок (authorConnectsBooks в твоем примере).
первое - это отношения один ко многим, в которых вам не нужна дополнительная таблица. Только две таблицы должны работать. Но во втором случае, поскольку это много-многозначное взаимодействие, вам потребуется добавить дополнительную таблицу, известную как Junction или таблицу перекрестных ссылок, поскольку большинство систем управления базами данных поддерживают только отношения «один ко многим», это необходимо реализовать такие отношения вручную через третью соединительную таблицу. Первичный ключ соединительной таблицы обычно формируется с использованием первичных ключей таблиц, которые он соединяет. Вот вики-страница, которая объясняет тот же самый пример, который вы просили:
а второй показывает отношение многие ко многим.
Пример скажем, мы используем первый пример
Author
AuthorID
Book
BookID
AuthorID
Как бы вы представили, что Джейн и Джон написали книгу «Stackoverflow для удовольствия»? В этой таблице отношений вы не можете, вы заявили, что один автор может написать много книг. Так что либо Джейн написала это, либо Джон написал это. Если бы только один из них написал книги, вы могли бы использовать этот тип отношений. Однако, если вы хотите показать, что оба написали эту книгу, вам понадобятся отношения многие ко многим.
Теперь, используя ту же аналогию с Джейн и Джоном, вы можете представить обоих авторов в одной книге, используя второй пример - отношения «многие ко многим».
Давайте используем Stackoverflow в качестве примера, начиная с отношения один ко многим и заканчивая отношением многие ко многим:Authors
Joel
Jeff
Books
Stackoverflow Joel
Бедный Джефф, ему не приписывают stackoverflow из приведенного выше примера ... поэтому нам нужно это исправить:
Author
Joel
Jeff
Books
Stackoverflow
AuthorBooks
Stackoverflow Jeff
Stackoverflow Joel
Теперь все счастливы ...