Каким стандартам я должен следовать при именовании таблиц и представлений?

20

Каким стандартам я должен следовать при именовании таблиц и представлений? Например, стоит ли ставить что-то вроде tbl_ в начале имен таблиц? Должен ли я обозначать таблицы кода / поиска каким-либо образом, например, ct_, lut_ или codes_? Есть ли что-нибудь еще, что можно / нельзя делать?

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

relational-theory naming-convention

— Бет Уайтцель
источник

29

Хорошо, сначала НИКОГДА не ставьте табличку перед именем таблицы. Это таблица, мы уже сейчас, что. Это называется венгерской нотацией, и люди перестали это делать 5+ лет назад.

Просто назовите объект, основываясь на том, что он есть. Если таблица содержит данные сотрудника, назовите ее «Сотрудник». Если он содержит информацию о компьютерах, назовите его «Компьютер». Если он сопоставляет компьютеры сотрудникам, назовите его «EmployeeComputer» или «ComputerEmployee» (лично мне больше нравится «EmployeeComputer»).

Нет реального соглашения об именах (кроме использования венгерской нотации). Пока имена объектов имеют смысл, это то, что важно.

— mrdenny
источник

11

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

— Marian

1

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

— Мрденный

2

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

— Бет Уайтзел

2

Ответ и следующие contributers г Денни резервируются этим: dba4life.blogspot.com/2007/11/...

1

@Marian: я использую множественное число, потому что они делают запросы более понятными и разрешают конфликты с ключевыми словами. Многие системы, с которыми я работал, имели сущность заказа. Использование множественных делает имя таблицы ordersне orderи избегает того , чтобы экранируют имя таблицы каждый раз , когда это пользователи. Это касается groupи других ключевых слов. К счастью, несколько ключевых слов сталкиваются с общими объектами.

— BillThor

13

Мы используем схемы (возможно, в SQL они рассматриваются как пространства имен) как для разрешений, так и для группировки. Таким образом, вместо "TBL" и т. Д. Мы имеем

Data.Thing
Data.ThingHistory
Data.Stuff

Ни один код не входит в схему данных. Таблицы не находятся вне схемы Data. Конечно, это может быть расширено, чтобы иметь схему Lookup или Staging, если хотите.

Для представлений, которые мы используем, vwно это было для того, чтобы отличать их от таблиц в SQL Server 2000, и теперь это своего рода наследие

— ГБН
источник

3

+1 за рекомендацию схем. Это пригодится при сохранении больших БД с сотнями таблиц. Мы также используем схемы для функциональной группировки ... как в AdventureWorks db

— CoderHawk

5

Лично я большой поклонник Fanö Bedingung , имея в виду, что не имя может быть началом другого действительного имени.

Во-вторых, расстояние Хэмминга между двумя именами лучше, чем одна другая буква.

Да, это правило с предродовых времен, но они облегчают жизнь.

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

— bernd_k
источник

2

Когда распознавание голоса станет правдой, я все равно сойду с ума. :-)

— Бет Уайтзел

Только если вы поддерживаете

— telethon

1

Когда узнается голос, я собираюсь стать водителем грузовика. Это или сумасшедший отшельник.

— Мрденный

Не могли бы вы объяснить более подробно (возможно, на примере), что такое «Fano Bedingung»?

— Ник Чаммас

1

@NickChammas Я думаю, что на английском мы называем это кодированием Шеннона-Фано .

— Иэн Самуэль Маклин, старейшина

2

Я не знаю, существует ли на самом деле какое-либо «лучшее» соглашение об именах, поскольку оно действительно сводится к личным предпочтениям и простоте разработки. Мой совет - выбрать соглашение об именах и придерживаться его. Если вы хотите отделить слова подчеркиванием, сделайте это во всех ваших объектах базы данных. Если вы хотите использовать camelCase, делайте это во всех ваших объектах базы данных.

В моем магазине мы придерживаемся следующих правил:

Мы разделяем слова подчеркиванием и используем все строчные буквы.
Наши имена таблиц описывают, что они из себя представляют: dbo.person, dbo.invoice.
Наши имена таблиц «многие ко многим» также описывают, какие они есть (с добавлением « мм» для обозначения отображаемого отношения «многие ко многим»: dbo.person_mm_address. Наши пользовательские хранимые процедуры описывают как объект, так и выполняемое действие: usp_person_select) , usp_address_select_by_city Наши представления и функции следуют тем же правилам, что и хранимые процедуры.Наши индексы включают таблицу, ключевые столбцы (по порядку) и указание кластеризованных / некластеризованных: ix_person_last_name_first_name_nc

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

Я надеюсь, что этот «не ответ» поможет каким-то образом.

— Мэтт М
источник

2

Я доволен этим с давних пор

имена таблиц: маленькие заглавные буквы и подчеркивания, единственное число {клиент, продукт}
имена таблиц для отношений «многие ко многим»: tablename1_tablename2: {customer_product}
просмотры: маленькие заглавные буквы добавлены в конец {customerv, productv, product_groupv}
сохраненные процедуры: имя таблицы и функция {customer_select, customer_insert, customer_delete, customer_update}

если у вас есть дешевый пакет виртуального хостинга, вам нужно использовать аббревиатуру проекта перед всеми вашими объектами, такими как, например, сайт администраторов баз данных, da_users, da_questions

— Угур Гюмюшан
источник

Почему бы product_groupvи не product_group_vдля представлений (если вы настаиваете на этом разделении представлений и таблиц)?

— ypercubeᵀᴹ

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

— Угур Гюмюшан