Использование VARCHAR как PRIMARY KEY для таблицы «ORPHAN»

Question

Я должен создать таблицу сирот (без каких-либо связей с какой-либо другой таблицей), которая содержит 3 столбца.

• Col1 - поле String - VARCHAR (32) - содержит уникальные данные, не более 32 символов
• Col2 - Строка поля - ТЕКСТ - содержит большие неуникальными данные символов
• Col3 - Числовые (Bool) - INT (1) - 0/1 для флага

Я думаю об использовании Col1 в качестве моего ПЕРВИЧНОГО КЛЮЧА. Я провел некоторое исследование и увидел, что люди утверждают, что использование бессмысленного столбца INT в качестве ПЕРВИЧНОГО КЛЮЧА, чтобы избежать проблем с внешним ключом/хранилищем, - это путь.

Однако ИМО, так как это сирота, это не имеет значения. Кроме того, мне потребовалось бы разместить INDEX на Col1 в любом случае.

В качестве дополнительной заметки я не ожидаю более 1000 строк в этой таблице.

Мысли, пожалуйста.

Answer 1

Если col1 является вашим действительным основным ключом, нет причин не использовать его. Особенно, если таблица такая крошечная.

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

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

Answer 2

В данном сценарии должно быть все в порядке. Если масштаб растет, вы всегда можете ввести столбец PK auto_increment. Просто убедитесь, что ваше поле индексировано и уникально.

Answer 3

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

Answer 4

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

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

Answer 5

Я бы все еще использовал INT PK и поместил индекс на COL1. Я полагаю, вы могли бы использовать COL1 в качестве индекса, если вы можете убедиться, что ничто никогда не будет присоединено к этой таблице, но если ничто иное, то индекс не даст вам представление о порядке, в котором элементы добавляются/удаляются из таблицы. Я также хотел бы добавить логическое значение IsActive, чтобы вы никогда не удаляли ничего и DateCreated datetime почти для каждой таблицы.

Answer 6

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

1. Это хорошо использовать VARCHAR вместо INTEGER в качестве первичного ключа?
   • Да, это нормально использовать VARCHAR.
     Во многих случаях это предпочтительнее, особенно если ваша таблица, как ожидается, вырастет выше 2 147 483 647 записей (да, это происходит). Производительность, даже если INTs имеет минимальное преимущество в скорости, в таблице 1000 записей, вы ее не увидите. Обозначенные ПК индексируются по умолчанию. Одна из проблем заключается в том, что вы потеряете любую автоматически генерирующую последовательность, которую база данных может сделать для вас.
2. Можно ли использовать свое уникальное поле COL1 в качестве первичного ключа вместо другого уникального идентификационного поля?
   • Да, все в порядке.
     Все понятие первичного ключа заключается в создании уникального поля. Однако то, что вы теряете, может быть каким-то внутренним пониманием. Когда другие пользователи хотят присоединиться к этой таблице, гораздо легче понять, что id является уникальным полем, тогда как col1 (некоторые varchar) могут быть или не быть уникальными.