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

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

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

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

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

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

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

• Data.Thing
• Data.ThingHistory
• Data.Stuff

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

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

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

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

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

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

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

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

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

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

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

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

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

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