Определение основной и внешней таблицы в отношениях? - PullRequest
5 голосов
/ 16 сентября 2009

При проектировании базы данных, что обычно определяет, какие таблицы будут основной и внешней таблицей в отношениях?

Например, если у меня есть таблица с именем posts и она содержит столбец id и postid, а у меня есть таблица с именем comments, и она содержит столбец с именем postid. Какая из этих таблиц будет основной в отношениях. Я бы предположил, что это таблица сообщений. Я говорю это потому, что это отношение один ко многим, и кажется, что таблица с одной записью будет основной, а таблица с множеством будет внешней таблицей.

Как насчет отношений «многие ко многим» или «1: 1», каковы основные и внешние таблицы в этих сценариях?

Ответы [ 4 ]

4 голосов
/ 16 сентября 2009

Основная таблица содержит родительские записи, те записи, которые определяют корневые записи, такие как «записи» в этом примере.

Внешние таблицы содержат дочерние записи, те записи, которые добавляют данные в родительские записи связанным способом.

Итак, «комментарий» является потомком «поста», поэтому: «Post» является родительским (основной в вашем примере) «Комментарий» - это ребенок (иностранный в вашем примере)

Значения PostId должны быть уникальными в таблице Post ... но одно и то же значение PostId может встречаться несколько раз в таблице комментариев (поскольку для одного сообщения может быть много комментариев; комментарий 1 для сообщения 1, комментарий 2 для сообщения 1).

1-1 отношения, когда два объекта являются равноправными. то есть студент может быть пользователем, а пользователь может быть студентом. Два студента не могут быть одним и тем же пользователем. Два пользователя не могут быть одним и тем же студентом. Поэтому пользователь - студент 1-1.

Многие ко многим отношениям лучше всего моделировать таблицу между ними.

Книга (основная)
Автор (основной)
АвторКниги (картография)

BookId уникален в Книгах (только одна книга может иметь определенный идентификатор)
AuthorId уникален у авторов (только один автор может иметь определенный идентификатор)

AuthorBooks содержит столбцы BookId и AuthorId и сопоставляет книги с авторами.

Это отношение смоделировано, потому что автор, возможно, написал много книг, и потому что у конкретной книги может быть много авторов.

3 голосов
/ 16 сентября 2009

Дано:

table posts
post_id

table comments
comment_id
post_id

table posts_to_comments
post_comment_id
post_id
comment_id
  • posts.post_id - это первичный ключ для сообщений в таблице.
  • comments.comment_id - это первичный ключ для комментариев к таблице.
  • comments.post_id - это внешний ключ к сообщениям таблицы.

сообщения будут вашей "основной" таблицей, как вы думаете об этом.

Для отношений многие-многие: (здесь не имеет особого смысла, но в любом случае)

  • posts_to_comments.post_comment_id is primary key
  • posts_to_comments.post_id is foreign key to posts
  • posts_to_comments.comment_id is foreign key to comments
2 голосов
/ 16 сентября 2009

Я никогда не слышал о первичных и иностранных, используемых для обозначения таблиц. Они характерны для колонн.

В приведенном вами примере:

  • в сообщениях, столбец postid является первичным ключом для таблицы сообщений
  • в комментариях столбец postid является обычным полем для таблицы Comments и обозначает уникальную строку в таблице Posts; он называется внешним ключом для сообщений (= ключ другой таблицы).
1 голос
/ 16 сентября 2009

Для многих-многих отношений, таких как Сети и Пользователи , где сети могут иметь много участников, а пользователи могут принадлежать ко многим сетям, вам нужно ввести третью таблица, которую можно назвать как-то так (выберите то, что вам больше подходит):

  • Networks_Have_Members
  • Users_BelongsTo_Networks
  • NetworkMembers

Эта таблица будет иметь составной первичный ключ, состоящий из userId и networkId. Кроме того, userId будет ссылаться на Users.id в качестве внешнего ключа, а networkId будет ссылаться на Networks.id в качестве внешнего ключа.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...