правильно называя поле id таблицы

Question

Я сейчас читаю книгу «Стиль программирования SQL», написанную Джо Селко.

В первой главе в параграфе «Разработка стандартных постфиксов» он указывает для столбца id:

"_ id" = идентификатор.Он уникален в схеме и ссылается на один объект в любом месте, где он появляется в схеме.Никогда не используйте "> table_name <_id" </p>

Несколько страниц спустя он заявляет

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

Он устарел "id" в качестве имени столбца.

Так что я хотел бы знать, как вы, ребята, называете столбец id?

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

Answer 1

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

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

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

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

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

Answer 2

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

Я использую модель tablename + 'id': UserId, PersonId и т. Д.

Answer 3

Вместо того, чтобы делиться своим мнением о стандартах именования, я попытаюсь ответить на ваш вопрос;)

Я думаю, что цель Celko состоит в том, что student_ID в таблице студентов - это запах кода, то естьбудь то, что стиль дизайнера заключается в том, чтобы всегда добавлять столбец идентификатора, возможно, столбец автоинкремента, к каждой таблице, которую они создают в физической модели (даже если в логической модели такого столбца нет) с намерением использовать эти столбцы идентификаторовдля внешних ключей.Другими словами, Челко не хочет, чтобы вы всегда использовали суррогатный ключ, скорее он хочет, чтобы вы использовали естественные ключи там, где это необходимо.

Если вы читаете раздел 1.2.5 (с. 14-15) и соблюдаете его правиладля имен таблиц вы поймете, почему имя таблицы + _ID маловероятно:

, если я не могу найти отраслевой стандарт (имя), я буду искать имя коллектива или класса ... Исключение: используйте имя в единственном числе, если в таблице есть одна-единственная строка.

Так, например, если у вас есть таблица, содержащая данные об учениках, она может называться «Студенты», а не «Студент», но болееВероятно, будет зачисление (или подобное).И таблица, содержащая одну и только одну строку, вряд ли нуждается в столбце _ID.

Я полагаю, что существуют существительные, для которых множественное число такое же, как и единственное число, поэтому, возможно, Sheep_ID является приемлемым (но только при отсутствииКонечно, отраслевой стандарт идентификатора овец!)

Также рассмотрим правило 1.3.2.(p19) Избегайте имен, которые меняются с места на место, например, тот же домен, который указан в таблице учеников как ID, а в других таблицах как student_ID.Вряд ли во всей схеме будет только один элемент с именем _ID!

Answer 4

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

Answer 5

Для идентификаторов таблиц я всегда использую имя таблицы + идентификатор.

Причина этого состоит в том, чтобы избежать неоднозначных имен столбцов в запросах, когда это отображение 1 к 1

Иногда я быстро пишу sql для проверки, как это

Select
  * 
FROM table1
Inner join table2 on table1ID = table2ID

Если бы я не использовал имя таблицы в столбце идентификатора, это вызвало бы ошибку (вынудив меня использовать псевдонимы в таблицах)

Select
  * 
FROM table1
Inner join table2 on ID = ID

Также еще одна веская причина использовать имя таблицы, в общем тестировании запросов, чтобы увидеть, какие данные существуют, используйте «*» для выбора столбцов. Если вы выполняете объединение и выбираете *, иногда трудно понять, какой идентификатор пришел из какой таблицы, особенно если вы возвращаете большое количество столбцов из более чем 2 таблиц

Answer 6

В моей базе данных:

Для идентификатора внешнего ключа я использую единственную версию имени внешней таблицы + "Id".Я использую заглавную букву I, ниже d, так как это стандарт, укоренившийся во мне в копе FX.

Для автоматического увеличения тождеств я часто использую «SequenceId»

В моем слое данных

Я использую имя объекта + «Id», следуя передовым стандартам для «Id»

Answer 7

Ух ты, я собирался написать «Я всегда использую TablenameID, но все остальные в мире не согласны со мной». Тем не менее, похоже, что все здесь согласны со мной.

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

Answer 8

ID в качестве имени столбца сложно поддерживать, и, на мой взгляд, это может привести к ошибкам в объединениях.

Предположим, например, что вы всегда использовали ID в качестве имени столбца в каждой таблице.

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

create table #test1 (id int identity, test varchar(10))
create table #test2 (id int identity, test varchar(10))
create table #test3 (id int identity, test varchar(10))

insert #test1
values ('hi')
insert #test1
values ('hello')
insert #test2
values ('hi there')
insert #test3
values ('hello')
insert #test3
values ('hi')
select * 
from #test1 t1
join #test2 t2
    on t1.id = t2.id
join #test3  t3
    on t1.id = t2.id    
select * 
from #test1 t1
join #test2 t2
    on t1.id = t2.id
join #test3  t3
    on t1.id = t3.id        

Drop table #test1
drop table #test2
drop table #test3   
Go

create table #test1 (t1id int identity, test varchar(10))
create table #test2 (t2id int identity, test varchar(10))
create table #test3 (t3id int identity, test varchar(10))   


    insert #test1
    values ('hi')
    insert #test1
    values ('hello')
    insert #test2
    values ('hi there')
    insert #test3
    values ('hello')
    insert #test3
    values ('hi')

select * 
from #test1 t1
join #test2 t2
    on t1.t1id = t2.t2id
join #test3 t3
    on t1.t1id = t3.t3id    

select * 
from #test1 t1
join #test2 t2
    on t1.t1id = t2.t2id
join #test3 t3
    on t1.t1id = t2.t3id    

    Drop table #test1
    drop table #test2
    drop table #test3   

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