Стандарты именования объектов базы данных

Часть III: ключевые столбцы

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

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

Правила именования столбцов первичного ключа

id или uid У каждой таблицы есть первичный ключ, и это всегда первый столбец таблицы. Это нарушает правило алфавитной последовательности, описанное в предыдущем посте, но кажется разумным исключением, учитывая важность этого столбца. Чтобы сделать вещи еще проще, есть только две возможности, когда дело доходит до именования столбца; используйте id или uid. Первый всегда имеет тип INT, а второй всегда, независимо от того, какую конкретную базу данных вы используете, указывает тип данных uuid. Предполагается, что столбцы практически не требуют затрат, так почему бы не иметь столбец, у которого нет другой задачи, кроме уникальной идентификации каждой записи. Это лучше, чем загромождать идентификационную роль какой-то другой деловой информацией.

Какой? Если вы знаете — действительно знаете — что созданная таблица будет служить абсолютным и окончательным ориентиром для остальной части вашего приложения, независимо от времени и пространства, тогда вы используете id. Однако используйте uid, если вы считаете, что существует возможность одновременного существования двух или более копий структуры таблицы, каждая из которых заполняется независимо друг от друга. Кроме того, если существует возможность, что эти две (или более) копии будут объединены в будущем, это закрывает сделку, это uid. Так что просто используйте uid, и вы будете защищены на тот случай, если в будущем захотите объединить таблицы. Таким образом, выбор между двумя типами первичных ключей зависит от того, является ли данная таблица вероятным кандидатом для репликации слиянием или нет.

Правила именования столбцов внешнего ключа

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

Добавить имя ссылочной таблицы Ссылочная таблица в примере, начатом в предыдущем пункте, — Breed. Это будет вторая часть имени внешнего ключа. Но он еще не совсем завершен, нужно как-то соединить два компонента. Для этого…

Разделение символом подчеркивания Ранее я критиковал использование символов подчеркивания или других символов при именовании объектов базы данных. Внешние ключи — большое исключение из этого правила. Я пришел к этому правилу методом исключения. Если ваши первичный и внешний ключи в данной таблице имеют значение id, у вас сразу возникает конфликт. Одним из вариантов было добавить префикс id к имени таблицы, например breedId. Неплохо, но слишком похоже на другие информационные столбцы таблицы. Итак, как насчет IdBreed? Да, но это противоречит идее о том, что квалификаторы всегда являются префиксами, а не суффиксами. Итак, это символ подчеркивания, в результате чего получается готовое имя Dog.id_Breed. Я подумал, что это особенно уместно, потому что подчеркивание действительно означает понятие разделения — визуальная метафора для данных в таблице, на которую ссылаются. Вы обнаружите, что они действительно выпрыгивают из определения при просмотре структур таблиц в будущем.

Поместить в конец таблицы Внешние ключи всегда находятся в конце определения таблицы. Они отображаются в алфавитном порядке в зависимости от имени таблицы, на которую ссылаются. Итак, если у вас есть три внешних ключа id_Breed, id_Colour и id_Association, они будут отображаться в определении таблицы следующим образом;

Dog.id_Association 
Dog.id_Breed 
Dog.id_Colour

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

Другие идеи

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

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

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

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

Эта серия статей была первоначально опубликована Теренсом С. Гэнноном в 2007 году в первоначальной версииблога Intellog. Поскольку мы приступаем к разработке новой базы данных с чистым листом для нового клиента, мы решили вернуться к этим исходным документам, чтобы проверить, выдержали ли они испытание временем. По большей части они есть, но мы также воспользовались возможностью немного обновить их для более современной эпохи. Мы хотели бы услышать ваши отзывы.

Стандарты именования объектов базы данных