Именование таблиц и представлений базы данных

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

Он думает, что akf хорошо ответил на вопрос. И HLGEM хорошо разбирается в рефакторинге.

Однако я бы добавил этот контраргумент к отсутствию условного обозначения префикса/суффикса. В SQL Server (и, возможно, в других базах данных) вы не можете иметь таблицу и представление с тем же именем в той же схеме с тем же владельцем. Это общий шаблон для создания денормализованного представления для таблицы. Если вы не приняли соглашение об именах, которое отличает представления от таблиц, тогда вы можете получить смешные имена для этих представлений, например EMPLOYEE_DENORM, вместо EMPLOYEE_V.

Если возникает необходимость в рефакторинге, таком как HLGEM, то это может означать ваше соглашение об именах. Таким образом, эти представления без префикса или суффикса легко идентифицируются как "рефакторинг".

Ответ 4

Использование префикса v_ или vw_ может быть полезно, если вы часто читаете запросы SELECT; вы можете быстро увидеть, выбираете ли вы из представления или таблицы. Префиксные представления или таблицы постфиксации должны быть достаточными, не нужно обоим. Мы используем префикс представления.

Кроме того, мы используем префикс "модуля" для таблиц кластеров и представлений вокруг функциональной группы. Например, таблицы биллинга называются BIL_ * и связанные с биллингами виды VW_BIL_ *. Именование модулей поддерживает связанные таблицы и представления рядом друг с другом в SSMS.

Ответ 5

От http://vyaskn.tripod.com/object_naming.htm:

Существует так много различных соглашений об именах для объектов базы данных, ни одна из них не является неправильной. Это более личное предпочтение человека, который разработал соглашение об именах. Однако в организации один человек (или группа) определяет соглашения об именах баз данных, стандартизирует его, а другие будут следить за ним, нравится им это или нет.

Прочтите полную статью для получения подробной информации о том, как реализовать/создать ее в вашей организации.

Ответ 6

Я предпочитаю называть мои таблицы во всех camelCase, а также имена полей. Например...

CREATE TABLE [crm].[company]
(
    [id] INT NOT NULL PRIMARY KEY,
    [companyName] NVARCHAR(255) NOT NULL
)

И для представлений я добавляю их со словом "вид". Например...

CREATE VIEW [crm].[viewFullEmployee]
    AS SELECT e.id, e.companyId, e.niceId, e.startDate, e.fullPart, p.firstName, p.middleName, p.lastName, p.active, p.birthDate, p.email, p.alternateEmail, p.phone, p.phoneExt, p.homePhone, p.mobilePhone, p.jobTitle, p.suffix, p.prefix FROM [crm].[Employee] as e FULL JOIN [crm].[person] as p on e.id = p.id

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

Я знаю, что что-то есть таблица из-за отсутствия представления слова перед ним. Это также предотвращает наличие таблицы и вида с тем же именем.

Я не люблю использовать имена подчёркиваний, такие как "employee_v", потому что я генерирую весь код уровня данных с шаблонами T4 "PetaPoco", и мне не нравится вводить _ в моем коде при обращении к типу.

Мне просто нравится это лучше

var person = uow.Db.Fetch<Models.viewFullEmployee>("SELECT * FROM [crm].[viewFullEmployee]");

против

var person = uow.Db.Fetch<Models.fullEmployee_V>("SELECT * FROM [crm].[fullEmployee_V]");

Что касается хранимых процедур, я считаю, что им не нужны префиксы типа "sp_", которые я вижу так много людей. Вы знаете, что это хранимая процедура, используемая из-за префикса EXEC или Create Procedure или Alter Procedure. Поэтому я называю свои хранимые процедуры, такие как "addUpdatePerson", "getUserPermissions" и т.д.

Где я использую префикс для функций, таких как "fnValidateEmail", поскольку они могут сталкиваться с именами хранимых процедур.