Должен ли я назначать первичный ключ для каждой таблицы в ORM? [Дубликат]

Хорошая практика иметь ПК на каждом столе, но это НЕ ДОЛЖНО. Скорее всего, вам понадобится уникальный индекс и / или кластерный индекс (который является PK или нет) в зависимости от ваших потребностей.

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

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

Но затем проверьте это также: http://www.aisintl.com/case/primary_and_foreign_key.html

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

Вы говорите, что у вас нет естественного ключа, поэтому у вас нет никаких комбинаций

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

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

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

Marc

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

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

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

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

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

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

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

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

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