2010-11-21 3 views
2

В настоящее время я читаю книгу «Стиль программирования SQL», написанную Джо Селко.Именование поля идентификатора таблицы правильно

В первой главе, в пункте "Разработка стандартизированного Postfixes" он утверждает, для столбца ID:

"_id" = идентификатор. Он уникален в схеме и относится к одному объекту везде, где он представлен в схеме. Никогда пользователь «> table_name < _id»

через несколько страниц он утверждает

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

Он устарел «id» как название столбца.

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

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

+0

Я предполагаю, что вы имеете в виду замену id? Обычно я использую что-то, что относится к этой таблице, например, к таблице «users» у меня будет идентификатор пользователя. – Elliott

+0

Противоположность префикса - суффикс. –

+0

@HLGEM Итак, что должно быть неясным? Я не могу понять, что он предлагает – Spredzy

ответ

1

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

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

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

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

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

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

рассмотреть также правила 1.3. 2. (p19) Избегайте имен, которые изменяются с места на место, например. тот же домен, указанный в таблице «Студенты» как идентификатор, и в других таблицах как student_ID. Маловероятно, что на всей схеме будет только один элемент с именем _ID!

1

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

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

Иногда я быстро писать SQL, чтобы проверить, как этот

Select 
    * 
FROM table1 
Inner join table2 on table1ID = table2ID 

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

Select 
    * 
FROM table1 
Inner join table2 on ID = ID 

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

+1

Изжога, которую я имею с помощью только идентификатора, состоит в том, что одно и то же имя присваивается столбцам с радикально различными значениями. Вы бы назвали 7 столбцов в 7 разных таблицах «ЦЕНА», если они не означали одно и то же? Разве вы не хотели бы называть их «WHOLESALE_PRICE», «EXTENDED_PRICE», «SUGGESTED_RETAIL_PRICE»? Именование PK и FK одинаковым (когда это возможно) означает, что недостающие ограничения можно найти очень легко. Некоторые инструменты ERD вызывают ограничение, если в другой таблице есть столбец PK и один и тот же столбец. Они не конкатенируют, чтобы вывести такие. –

+1

@Stephanie ... Я думаю, что вы неправильно поняли мой ответ. Я согласен с полным. –

+0

Да, помощь поможет объяснить, что вы хотели сказать! спасибо за ясность. –

2

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

Я использую имя_таблицы + «ID» Модель: UserId, PersonId и т.д.

+0

Я использую ту же модель. Очень удобно, потому что вы всегда знаете имя поля id и никогда не путаетесь в соединениях. Для FK я использую одно и то же имя, поэтому CustomerId в таблице заказов также называется CustomerId. Этот метод все еще отлично работает в приложении из 1000 таблиц и некоторых довольно сложных запросах, и он отлично меня обслуживает. – GolezTrol

3

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

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

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

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

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

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

+0

Обычно, когда я попадал в исключения, вы указываете, что я использую что-то вроде personId, supervisorPersonId. Таким образом, у меня есть точное имя идентификатора, к которому мне нужно присоединиться, но с квалификатором префикса, что делает его более четким. – HLGEM

0

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 является то, что если вы хотите, фактический идентификатор из нескольких таблиц в сложной отчетности запроса, вы не должны создавать псевдонимы для того, чтобы увидеть, какие id пришел откуда (и сделать приложение отчетов счастливым, поскольку большинство из них inist по уникальным именам полей для отчета).

1

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

0

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

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

0

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

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

Для авто приращения идентичностей Я часто использую «SequenceId»

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

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

Смежные вопросы