Каждая таблица должна иметь первичный ключ?
Определите перечисление следующим образом:
public enum Face
{
A=1,
Two,
Three,
Four,
Five,
Six,
Seven,
Eight,
Nine,
Ten,
J,
Q,
K
}
Затем вы можете получить доступ к значению как целому числу, используя приведение (int)Face.J, которое даст вам 11. Пожалуйста, обратитесь к этой работе . Пример .
Обратите внимание: Вы можете назначить целочисленные значения для enum, если не назначено, то будет принято первое значение, так как 0 +1 будет добавлено к последующим элементам. Это означает, что если вы используете код (int)Face.J без присваивания, вы получите значение 10 вместо 11
12 ответов
Краткий ответ: да .
Длинный ответ:
- Вам нужно, чтобы ваша таблица была присоединяемой к чему-либо
- Если вы хотите, чтобы ваша таблица была кластеризованной, вам нужен какой-то первичный ключ.
- Если ваш дизайн таблицы не требует первичной ключ, переосмыслите свой дизайн: скорее всего, вы что-то упустили. Зачем хранить идентичные записи?
В MySQL механизм хранения InnoDB всегда создает первичный ключ, если вы не указали его явно, создавая дополнительный столбец, к которому у вас нет доступа.
Обратите внимание, что первичный ключ может быть составным.
Если у вас есть таблица ссылок «многие ко многим», вы создаете первичный ключ для всех полей, участвующих в ссылке. Таким образом, вы гарантируете, что у вас нет двух или более записей, описывающих одну ссылку.
Помимо проблем логической согласованности, большинство механизмов РСУБД получит выгоду от включения этих полей в уникальный индекс.
И поскольку любой первичный ключ включает создание уникальный индекс, вы должны объявить его и получить как логическую согласованность, так и производительность.
См. эту статью в моем блоге, почему вы всегда должны создавать уникальный индекс для уникальных данных:
PS
Практически каждый раз, когда я создавал таблицу без первичного ключа, думая, что он мне не нужен, я заканчивал тем, что возвращался и добавлял один. Теперь я даже создаю свои таблицы соединений с автоматически сгенерированным полем идентификации, которое я использую в качестве первичного ключа.
Короче говоря, нет. Однако необходимо помнить, что некоторые операции CRUD для клиентского доступа требуют этого. Для проверки будущего я всегда использую первичные ключи.
За исключением нескольких очень редких случаев (возможно, таблица отношений «многие ко многим» или таблица, которую вы временно используете для массового- загрузка огромных объемов данных), я бы сказал:
Если у него нет первичного ключа, это не таблица!
Марк
Просто добавьте его, позже вы пожалеете, что не сделали этого (выбор, удаление, связывание и т. Д.)
Я знаю, что для использования определенных функций gridview в .NET вам нужен первичный ключ, чтобы gridview узнал, какая строка нуждается в обновлении / удалении. Как правило, необходимо иметь первичный ключ или кластер первичных ключей. Лично я предпочитаю первое.
Чтобы сделать это надежным в будущем, вы действительно должны это сделать. Если вы хотите повторить его, вам он понадобится. Если вы захотите присоединить его к другому столу, ваша жизнь (и жизнь бедных дураков, которые должны содержать его в следующем году) будет намного проще.
Придется ли вам когда-нибудь присоединить этот стол к другим столам? Вам нужен способ однозначной идентификации записи? Если да, вам нужен первичный ключ. Предположим, что ваши данные - это что-то вроде таблицы клиентов, в которой есть имена людей, которые являются клиентами. Естественного ключа может не быть, потому что вам нужны адреса, электронные письма, номера телефонов и т. Д., Чтобы определить, отличается ли эта Салли Смит от этой Салли Смит, и вы будете хранить эту информацию в связанных таблицах, поскольку у человека может быть несколько телефонов, добавлений , электронные письма и т. д. Предположим, Салли Смит выходит замуж за Джона Джонса и становится Салли Джонс. Если у вас нет искусственного ключа на столе, при обновлении имени вы только что изменили 7 Салли Смит на Салли Джонс, хотя только одна из них вышла замуж и сменила имя. И, конечно же, в этом случае без искусственного ключа, как узнать, какая Салли Смит живет в Чикаго, а какая в Лос-Анджелесе?
Вы говорите, что у вас нет естественного ключа, поэтому у вас нет никаких комбинаций полей для создания также уникален, поэтому искусственный ключ становится критическим.
Я обнаружил, что всякий раз, когда у меня нет естественного ключа, искусственный ключ абсолютно необходим для поддержания целостности данных. Если у вас есть естественный ключ, вы можете использовать его в качестве ключевого поля. Но лично я предпочитаю искусственный ключ и уникальный индекс естественного ключа, если только естественный ключ не является одним полем. Вы пожалеете об этом позже, если не вставите его.
У меня также есть какие-либо комбинации полей, чтобы сделать их уникальными, это делает искусственный ключ критическим.Я обнаружил, что всякий раз, когда у меня нет естественного ключа, искусственный ключ абсолютно необходим для поддержания целостности данных. Если у вас есть естественный ключ, вы можете использовать его в качестве ключевого поля. Но лично я предпочитаю искусственный ключ и уникальный индекс естественного ключа, если только естественный ключ не является одним полем. Вы пожалеете об этом позже, если не вставите его.
У меня также есть какие-либо комбинации полей, чтобы сделать их уникальными, это делает искусственный ключ критическим.Я обнаружил, что всякий раз, когда у меня нет естественного ключа, искусственный ключ абсолютно необходим для поддержания целостности данных. Если у вас есть естественный ключ, вы можете использовать его в качестве ключевого поля. Но лично я предпочитаю искусственный ключ и уникальный индекс естественного ключа, если только естественный ключ не является одним полем. Вы пожалеете об этом позже, если не вставите его.
У меня всегда есть первичный ключ, даже если вначале у меня еще нет цели для него. Было несколько раз, когда мне в конечном итоге понадобился ПК в таблице, у которой его нет, и всегда сложнее вставить его позже. Я думаю, что всегда есть один положительный момент.
Если вы используете Hibernate, невозможно создать Entity без первичного ключа. Эта проблема может создать проблему, если вы работаете с существующей базой данных, которая была создана с помощью простых сценариев sql / ddl, и не был добавлен первичный ключ
Всегда лучше иметь первичный ключ. Таким образом, он соответствует первой нормальной форме и позволяет продолжить путь нормализации базы данных .
Как утверждали другие, есть некоторые причины не иметь первичный ключ, но большинство из них не пострадают, если будет первичный ключ
Я занимаюсь поддержкой приложения, созданного оффшорной командой разработчиков. Теперь у меня возникают всевозможные проблемы в приложении, потому что исходная схема базы данных не содержала ПЕРВИЧНЫХ КЛЮЧЕЙ для некоторых таблиц. Поэтому, пожалуйста, не позволяйте другим людям страдать из-за вашего плохого дизайна. Всегда полезно иметь первичные ключи в таблицах.