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

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

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

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

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

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

Марк

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

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

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

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

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

Проверьте разделы первичные ключи и кластеризованные индексы в электронной документации (для SQL Server)

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

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

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

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

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

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

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

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