Выбор первичного ключа - PullRequest
       6

Выбор первичного ключа

0 голосов
/ 23 декабря 2011

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

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

name            | type        | content   |
--------------------------------------
John Doe        | overview    | some text |
----------------------------------------
John Doe        | background  | some text |
----------------------------------------
John Doe        | height      | some text |
----------------------------------------
Fred Flintstone | overview    | some text |
---------------------------------------
Fred Flintstone | background  | some text |

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

Что ты думаешь? нужен первичный ключ? Если так, что это должно быть?

Ответы [ 3 ]

4 голосов
/ 23 декабря 2011

Я бы, конечно, пошел за Auto Increment primary ID. Это то, для чего он нужен, он упрощает поддержку и обновление таблицы, а также намного проще связывать другие таблицы в реляционной установке.

Существует также вопрос производительности при поиске записей.

Подводя итог:

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

См .: http://code.openark.org/blog/mysql/reasons-to-use-auto_increment-columns-on-innodb

1 голос
/ 03 января 2012

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

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

id  | name            | type        | content   |
--------------------------------------
1   | John Doe        | overview    | some text |
2   | John Doe        | overview    | some text |
3   | John Doe        | overview    | some text |
4   | John Doe        | overview    | some text |

Сколько разных людей? (Есть 3. Джон Дел с идентификаторами 1 и 3 - это одно и то же лицо.) УНИКАЛЬНОЕ ограничение на {имя, тип} также не поможет, потому что это позволит только одному человеку по имени "Джон Доу" базы данных.

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

1 голос
/ 23 декабря 2011

Я бы предложил вам создать столбец идентификатора в качестве первичного ключа и создать еще одну таблицу, которая будет отображать записи, такие как обзор, фон, высота

id overview  background height 
1      1           3         5

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

...