Альтернатива многим отношениям

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

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

Я думал просто поместить внешний ключ в каждый стол, поэтому у меня есть authoridFK в таблице моих книг и bookIdFK в таблице моих авторов. Но я не уверен, каким будет тип отношений, будет ли он меня правильно и как он будет выглядеть на ERD?

Может ли кто-нибудь прояснить их мне?

источник

2016-12-07 Robert Ross

Как новичок, то почему бы вам не попробовать реализовать это правильно и учиться на этом пути? Правильным вариантом будет реализация объекта пересечения в вашей базе данных, как вы изначально отметили. Другие определения таблиц, которые вы предлагаете, сделают вашу жизнь более сложной, когда вам нужно будет добавить дополнительные реляционные данные. – Brendan

* Правильный * способ - это тот, который вы пытаетесь избежать. Три таблицы: авторы, книги и таблица отношений, которая связывает их. – Santi

Спасибо за ответы. Вы в порядке, но мне интересно, это единственный способ сделать это. Предположим, я хочу денормировать от 3-й до 2-й формы. Как бы это реализовать? –

«Лучший», и наиболее стандартным способом является использование третьей таблицы для поддержания отношений.

Что касается сложности запроса, вы можете либо изучить JOIN в своих запросах, либо получить ORM, который обрабатывает эти типы отношений для вас.

Пример объединяющего запроса для данного контекста, который будет возвращать список всех авторов и все книги, которые они внесли свой вклад будет выглядеть следующим образом:

select a.AuthorName, b.BookName 
from author a 
    join AuthorBookMapping m on m.AuthorID = a.AuthorID 
    join Book b on m.BookID = b.BookID

источник

2016-12-07 21:45:52 djdduty

ответ

Смежные вопросы