Альтернативные имена для суррогатного ключа / порядкового номера / столбца идентификатора

Question

У меня есть устаревшая таблица, которая имеет как часть своего естественного ключа столбец с именем <table_name>_IDENTIFIER, и кажется, что было бы сложно создать суррогатный ключ с именем <table_name>_ID или ID, поэтому я склоняюсь кназвав это SURROGATE_KEY.Все мои другие таблицы используют синтаксис <table_name>_ID.Есть лучшие предложения?

Answer 1

Не называйте это SURROGATE_KEY.Это бессмысленно в любом другом контексте.Я бы придерживался <table_name>_ID.Да, это немного сбивает с толку.Но, учитывая ваше установленное соглашение, все остальное тоже может сбить с толку.

Answer 2

Я мог бы предложить вам использовать ваш стандарт: <table_name>_ID

В конце концов, устаревшая таблица не будет движущей силой, и это будет столбец ИДЕНТИФИКАТОР, который будет выглядеть странно, что выхочу, в отличие от этого - «о да, мне нужно использовать surrogate_key для этой вещи вместо id ...».

Answer 3

Во-первых, я бы не включил имя таблицы в мои столбцы.Столбец - это атрибут, который требует контекста объекта, которому он принадлежит.Например, иметь «имя» без контекста, к которому оно принадлежит, бесполезно.Вы должны знать, что это имя лица или название компании и т. Д., И вы должны указать это на имя самой организации.Таким образом, я бы не ставил перед столбцами префикс с именем таблицы, в которой он объявлен.

Это оставляет вас с такими вариантами выбора, как «Id», «Key», «SurrogateKey» или, возможно, «SystemId», которые все одинаково неопределенны.По крайней мере, «SurrogateKey» описывает, что это такое, что является бонусом.Это имя будет иметь смысл для администратора баз данных, но, возможно, не для разработчика (хотя они должны понимать концепцию).Из этих вариантов я был бы склонен использовать «Id» и найти способ изменить <table_name>_Identifier на что-то более описательное.

Answer 4

Согласовано. , , SURROGATE_ID не рекомендуется. Чего не хватает всем предложениям, так это в самом сердце лучших практик управления данными и моделирования данных: создание (и последовательное использование!) Соглашений об именах и доменов значений. Предложения:
1. Если для базы данных или протокола программирования (например, .NET, который ненавидит естественные первичные ключи, как я уже понял) требуется единственное бессмысленное целое число, назначенное в качестве первичного ключа - суррогатного - ключа, то создайте значение домен "Id" и определите его как целочисленный тип данных с описанием суррогатного первичного ключа. 2. При именовании атрибутов / столбцов ЕДИНСТВЕННЫЕ столбцы, использующие домен «Id», будут столбцами суррогатного (первичного) ключа, заполненными назначенными целочисленными значениями. Никаким другим атрибутам / столбцам не будет разрешено использовать домен "Id", поэтому из имени атрибута / столбца будет абсолютно ясно, характер сохраненных значений И как эти значения начинают использоваться. Спасибо за предоставленную возможность!

Answer 5

В мире моделирования данных во время рисования модели ER суррогатный ключ, такой как SURROGATE_KEY (или SURROGATE_ID), безусловно, вызовет побочные эффекты боли при создании ограничения внешнего ключа.

т.е. связывание родителя с потомком в большинстве инструментов DM с помощью первичного ключа dragg-n-drop автоматически создаст идентичный столбец в потомке, создавая дубликаты в именах столбцов.

Чтобы избежать этого, как правило, рекомендуется использовать имя суррогатного ключа, например Table_name.Table_name_ID или Table_name._ID.