Каков наилучший способ справиться с этими отношениями базы данных MySQL? - PullRequest
Новая
       3

Каков наилучший способ справиться с этими отношениями базы данных MySQL?

1 голос
/ 22 января 2011

Я создаю небольшой веб-сайт, который позволяет пользователям рекомендовать свои любимые книги друг другу. Итак, у меня есть две таблицы, книги и группы. Пользователь может иметь 0 или более книг в своей библиотеке, и книга принадлежит 1 или более группам. В настоящее время мои таблицы выглядят так: 

books table
|---------|------------|---------------|
| book_id | book_title | book_owner_id |
|---------|------------|---------------|
| 22      | something  | 12         |
|---------|------------|---------------|
| 23      | something2 | 12         |
|---------|------------|---------------|

groups table
|----------|------------|---------------|---------|
| group_id | group_name | book_owner_id | book_id |
|----------|------------|---------------|---------|
| 231      | random     | 12            | 22      |
|----------|------------|---------------|---------|
| 231      | random     | 12            | 23      |
|----------|------------|---------------|---------|

Как видите, отношения между пользователями + книгами и книгами + группами определены в таблицах. Должен ли я определить отношения в их собственных таблицах? Примерно так: 

books table
|---------|------------|
| book_id | book_title |
|---------|------------|
| 22      | something  |
|---------|------------|
| 23      | something2 |
|---------|------------|

books_users_relationsship table
|---------|------------|---------|
| rel_id  | user_id    | book_id |
|---------|------------|---------|
| 1       | 12         | 22   |
|---------|------------|---------|
| 2       | 12         | 23   |
|---------|------------|---------|

groups table
|----------|------------|
| group_id | group_name |
|----------|------------|
| 231      | random     | 
|----------|------------|

groups_books_relationsship table
|----------|---------|
| group_id | book_id |
|----------|---------|
| 231      | 22      |
|----------|---------|
| 231      | 23      |
|----------|---------|

Спасибо за ваше время.

Ответы [ 2 ]

2 голосов
/ 22 января 2011

Вторая форма с четырьмя таблицами является правильной. Вы можете удалить rel_id из books_users_relationsship, поскольку первичный ключ может быть составным с user_id и book_id, как в таблице groups_books_relationsship.

1 голос
/ 26 января 2011

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

Вторая проблема, с которой вы сталкиваетесь, причинаОтношения становятся сложными и даже необязательными из-за того, что первые две таблицы не нормализуются.Из этого вытекают многие проблемы.

  • Если вы внимательно посмотрите на book, вы можете заметить, что одно и то же book (название) повторяется

  • аналогично, нет различий между (а) книгой с точки зрения ее существования в мире и (б) копией книги, которая принадлежит члену и доступна для заимствования

    • например.обзор о существующем book, один раз, и применяется ко всем копиям book;не принадлежит book.
      .

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

  • Все эти повторяющиеся данные должныподдерживаться и синхронизироваться.

  • все эти проблемы устраняются, если данные нормализованы.

Поэтому (поскольку вы ищете "Наилучший способ "), последовательность состоит в том, чтобы сначала нормализовать данные, после чего (что неудивительно) отношения просты и не сложны, и данные не повторяются (ни в таблицах, ни в отношениях).

  • при нормализации лучше всего моделировать реальный мир (не весь реальный мир, а любые его части, которые вы внедряете в базу данных).Это изолирует вашу базу данных от последствий изменений, и функциональные расширения к ней в будущем не требуют изменения существующих таблиц.

  • Также важно использовать точные имена для таблиц истолбцы, по той же причине.group неспецифично и вызовет проблему в будущем при реализации какой-либо другой формы группировки.

  • Теперь отношения могут быть определены на правильном «уровне» междуправильные таблицы.

  • Необходимость прикреплять столбец Id ко всему, что движется, серьезно ограничивает вашу способность понимать данные и, таким образом, процесс нормализации, и лишает базу данных реляционной мощности.

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

    • ReviewerId, OwnerId и BorrowerId are all MemberIds` в качестве внешних ключей, показывающих явную роль, в которой они используются.

  • Обратите внимание, что в вашем проблемном пространствене так просто, как вы думаете, он используется в качестве учебного примера и поставляется с учебными пособиями по SQL (например, MS SQL, Sybase).

▶ СоциальныйМодель данных библиотеки ◀

Читатели, которые не знакомы со Стандартом моделирования реляционных баз данных, могут найти ▶ IDEF1X Notational ◀ полезным.

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

  • Эти вопросы очень важны, поскольку они определяют ссылочную целостность базы данных.

  • Также важно реализовать это в самой базе данных, которая является стандартным местоположением (а не в коде приложения повсюду).Декларативная ссылочная целостность является частью стандарта SQL IEC / ISO / ANSI.И вопрос имеет тег дизайна базы данных.

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

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

...