Проектирование баз данных и использование нечисловых Первичных ключей

** - указатель на указатель. Иногда они используются для массивов строк.

14
задан Nick Jennings 29 May 2009 в 10:00
поделиться

9 ответов

Есть 2 причины, по которым я всегда добавляю идентификационный номер в таблицу поиска / ENUM:

  1. Если вы ссылаетесь на таблицу с одним столбцом с именем, то вам может быть удобнее использовать ограничение
  2. Что произойдет, если вы захотите переименовать одну из записей client_status? например, если вы хотите изменить имя с «аффилированного» на «аффилированный пользователь», вам потребуется обновить таблицу клиентов, в чем нет необходимости. Идентификационный номер служит ссылкой, а имя - описанием.

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

РЕДАКТИРОВАТЬ: Как указано выше, вы столкнетесь с проблемами, если имя веб-сайта будет переименовано. Сделав это первичным ключом, вы сделаете очень трудным, если не невозможным, его изменение позже.

16
ответ дан 1 December 2019 в 06:31
поделиться

Создавая естественные ключи PRIMARY KEY , убедитесь, что их уникальность находится под вашим контролем.

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

Поскольку website_status и client_status , похоже, генерируются и используются вами и только вами , их можно использовать в качестве ПЕРВИЧНОГО КЛЮЧА , хотя наличие длинного ключа может повлиять на производительность.

website name, кажется, находится под контролем внешнего мира, поэтому я бы сделал это простое поле. Что, если они захотят переименовать свой веб-сайт ?

Контрпримеры: SSN и ZIP коды: it '

13
ответ дан 1 December 2019 в 06:31
поделиться

Кимберли Трипп опубликовала отличную серию статей в блоге ( GUID в качестве ПЕРВИЧНЫХ КЛЮЧЕЙ и / или ключ кластеризации и Продолжаются дебаты по кластеризованному индексу ) на проблема создания кластеризованных индексов и выбора первичного ключа (связанные вопросы, но не всегда точно такие же). Она рекомендует, чтобы кластеризованный индекс / первичный ключ был:

  1. Уникальным (в противном случае бесполезным в качестве ключа)
  2. Узким (ключ используется во всех некластеризованных индексах, а также во внешних ключевые отношения)
  3. Статический (вы не хотите изменять все связанные записи)
  4. Всегда возрастает (поэтому новые записи всегда добавляются в конец таблицы, а не должны быть вставлены посередине)

Использование "Name" в качестве ключа, хотя это, кажется, удовлетворяет # 1, не t удовлетворить ЛЮБОЙ из трех других.

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

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

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

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

9
ответ дан 1 December 2019 в 06:31
поделиться

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

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

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

Например, если ваша таблица имеет 10 миллионов строк, 10 некластеризованных индексов и ваш ключ кластеризации составляет 26 байтов вместо 4 (для INT) , то вы тратите 10 млн. на 10 на 22 байта, всего 2,2 миллиарда байтов (или примерно 2,2 ГБ) - это уже не ерунда!

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

Marc

больше не арахис!

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

Marc

больше не арахис!

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

Marc

3
ответ дан 1 December 2019 в 06:31
поделиться

Это кажется действительно плохой идеей. Что, если вам нужно изменить значение перечисления? Идея состоит в том, чтобы сделать из нее реляционную базу данных, а не набор плоских файлов. Зачем на этом этапе таблица client_status? Более того, если вы используете данные в приложении, используя такой тип, как GUID или INT, вы можете проверить тип и избежать неверных данных (в том, что касается проверки типа). Таким образом, это еще один из многих способов сдерживания взлома.

1
ответ дан 1 December 2019 в 06:31
поделиться

Лично я думаю, что вы столкнетесь с проблемами, используя эту идею. По мере того, как у вас появляется больше родительских и дочерних отношений, вы получаете огромный объем работы, когда меняются имена (как всегда, рано или поздно). При обновлении дочерней таблицы, содержащей тысячи строк, при изменении имени веб-сайта может возникнуть большой удар производительности. И вы должны спланировать, как сделать так, чтобы эти изменения произошли. В противном случае имя веб-сайта изменится (к сожалению, мы допустили истечение срока действия имени и его купил кто-то другой) либо сломается из-за ограничения внешнего ключа, либо вам нужно будет ввести автоматический способ (каскадное обновление) для распространения изменения по системе. Если вы используете каскадные обновления, вы можете внезапно остановить свою систему на время обработки большого изменения. Это не считается хорошим делом. Действительно более эффективно и действенно использовать идентификаторы для отношений, а затем помещать уникальные индексы в поле имени, чтобы гарантировать их уникальность. При проектировании базы данных необходимо учитывать обеспечение целостности данных и то, как это повлияет на производительность.

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

1
ответ дан 1 December 2019 в 06:31
поделиться

Здесь следует учесть несколько моментов, прежде чем выбирать ключи в таблице

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

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

  • Цифровые клавиши делают вид базы данных проще понять (вы легко можете знать нет строк, просто взглянув на последнюю строку)
0
ответ дан 1 December 2019 в 06:31
поделиться

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

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

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

Вы также можете рассмотреть возможность использования сжатия индексного ключа, если ваша СУБД поддерживает это. Это может быть очень эффективным, особенно для индексов на составных ключах (подумайте о структурах данных trie ), и особенно если наименее избирательные атрибуты могут появиться первыми в индексе.

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

Вы также можете рассмотреть возможность использования сжатия индексного ключа, если ваша СУБД поддерживает это. Это может быть очень эффективным, особенно для индексов на составных ключах (подумайте о структурах данных trie ), и особенно если наименее избирательные атрибуты могут появиться первыми в индексе.

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

Вы также можете рассмотреть возможность использования сжатия индексного ключа, если ваша СУБД поддерживает это. Это может быть очень эффективным, особенно для индексов на составных ключах (подумайте о структурах данных trie ), и особенно если наименее избирательные атрибуты могут появиться первыми в индексе.

1
ответ дан 1 December 2019 в 06:31
поделиться

«Если вы абсолютно уверены, что никогда не столкнетесь с нарушением уникальности, тогда можно использовать эти значения в качестве ПЕРВИЧНЫХ КЛЮЧЕЙ».

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

2
ответ дан 1 December 2019 в 06:31
поделиться
Другие вопросы по тегам:

Похожие вопросы: