Должна ли каждая таблица иметь первичный ключ?

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

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

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

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

если у него нет первичного ключа, это не таблица!

Марк

вам когда-нибудь понадобится присоединиться к этой таблице к другим таблицам? Вам нужен способ уникальной идентификации записи? Если ответ да, вам нужен первичный ключ. Предположим, что ваши данные-это что-то вроде таблицы клиентов с именами людей, которые являются клиентами. Может не быть естественного ключа, потому что вам нужны адреса, электронные письма, номера телефонов и т. д. чтобы определить, отличается ли эта Салли Смит от этой Салли Смит, и вы будете хранить эту информацию в связанных таблицах, как человек может имейте mulitple телефоны, addesses, электронные почты, etc. Предположим, Салли Смит выходит замуж за Джона Джонса и становится Салли Джонс. Если у вас нет искусственного ключа на столе, когда вы обновляете имя, вы просто изменили 7 Салли Смит на Салли Джонс, хотя только один из них женился и изменил свое имя. И конечно, в этом случае без искусственного ключа Как узнать, какая Салли Смит живет в Чикаго, а какая в Лос-Анджелесе?

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

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

просто добавьте его, вы пожалеете позже, когда вы этого не сделали (выбор, удаление. связывание и т. д.)

Это хорошая практика, чтобы иметь ПК на каждом столе, но это не обязательно. Скорее всего, вам понадобится уникальный индекс и/или кластеризованный индекс (который является PK или нет) в зависимости от ваших потребностей.

Проверьте разделы первичные ключи и кластеризованные индексы в книгах в Интернете (для SQL Server)

"ограничения первичного ключа определяют столбец или набор столбцов со значениями, однозначно идентифицирующими строку в таблице. Никакие две строки в таблице не могут иметь одинаковые первичные ключевая ценность. Вы не можете ввести NULL для любого столбца в первичном ключе. В качестве первичного ключа рекомендуется использовать небольшой целочисленный столбец. Каждая таблица должна иметь первичный ключ. Столбец или сочетание столбцов, которые квалифицируются как значение первичного ключа, называется потенциальным ключом."

но тогда проверьте это также:http://www.aisintl.com/case/primary_and_foreign_key.html

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

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

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

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

Если вы используете Hibernate, невозможно создать объект без первичного ключа. Эти проблемы могут создать проблему, если вы работаете с существующей базой данных, которая была создана с помощью простых сценариев sql / ddl, и первичный ключ не был добавлен

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