Проектирование: Имена таблиц и полей БД

[skiperski]

Создавая объекты, логично и без всяческих побочных эффектов задать свойствам объекта имена Id, Name, Description и т.д. Имена свойств не вступают в конфликт с именами свойств других объектов. При именовании полей таблиц, казалось бы, можно было бы поступать так же, но.. При составных запросах одинаковые имена полей могут конфликтовать друг с другом и необходимо вводить псевдонимы. Отсюда следует, что имена лучше сразу давать уникальные. С другой стороны придумывать новые имена не так-то уж просто, они становятся длинными и неудобными в использовании. Некоторые используют в именах полей имя таблицы или его сокращённое название как префикс. Как это делаете вы?

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

Короче: Какой методологии придерживаетесь вы при именовании таблиц БД и полей в них? Можно также поделиться секретом именования объектов, их свойств, переменных, констант и т.п.

[alibek]

Ключевые поля: CLNT_ID, USER_ID, STAT_ID, PROP_ID, STR_ID (трех-четырехбуквенное сокращение, производимое от имени таблицы, после чего следует _ID). Внешние ключи, соответственно, CLNT_CLNT_ID, USER_USER_ID, STAT_STAT_ID, PROP_PROP_ID, STR_STR_ID. В случае внешнего ключа на внешний ключ CLNT_USER_ID и т.п.
Таблицы называть преимущественно во множественном числе (CLIENTS, STATES, USERS), в случае, если таблица является исторической, то в единственном числе, добавляя HISTORIES (CLIENT_HISTORIES, USER_HISTORIES). Если таблица является вспомогательноя для отношений M-M, то имя таблицы состоит из сокращенных названий составных таблиц (CLNT_USER, USER_STAT).
Остальные поля называть как угодно, но придерживаться единообразия. Т.е. в справочных таблицах (ключ-название элемента) описание будет хранится в поле TITLE, DEF или CAPTION, в ключевых таблицах запись будет иметь хранится в поле NAME. В NOTES хранятся примечания, в START_DATE, END_DATE (или DATE_START, DATE_END) отметки для исторических записей.

[Ennor]

На данный момент я еще не устаканил для себя схему именования (в отличие от VB), но пока это выглядит примерно так:
Таблица: Сущность (мн. ч.) - Orders
Поле: Атрибут сущности - ISOCode
Представление: View%Производное имя% (мн. ч.) - ViewCurrentSessions
Хранимая процедура: %Логический префикс%_%Описание действия% - documents_create(). В данном случае префикс documents является своего рода пространством имен, в пределах которого определяются те или иные операции. Разумеется, придумывалось в расчете на стандартные СУБД, т.к. например в Оракле имеется такая вещь, как package, которая вообще все привычное серверное программирование с ног на голову ставит. Да и в Юконе вроде как тоже понаверчено в этом вопросе.
Функция: а вот тут я до конца не определился. В зависимости от контекста, могу назвать как Get%Действие% (мн. ч., если функция возвращает таблицу с произвольным количеством строк, и ед. ч., если скалярная или возвращающая строго одну запись таблицы; но вообще когда как) - GetActiveOrders(), GetCurrentOperatorId(). А могу и без Get - как покажется созвучнее. Учитывая, что в MSSQL 2000 функции суть не что иное, как параметризованные вьюхи, выглядит вполне логично.

На имена производных объектов я обычно обращаю мало внимания, тут скорее не правила, а предпочтения:
Первичный ключ: PK_%TableName% - PK_Orders.
Альтернативный ключ: когда как. Если генерю схему в ERwin, то соглашаюсь с его AK_%TableName%?Number? - AK_Users1. Если же по-быстрому рисую табличку в SQL EM, то оставляю его префикс UQ_.
Индекс: IX_%DerivedAttributeName%?Number? в большинстве случаев - IX_CreateDate. Подобная развращенность пошла с сиквела, т.к. там имя индекса не обязано быть уникальным в пределах базы, только в пределах того объекта, к которому он относится. Правда, иногда по привычке дополнительно вставляю в середину имя объекта - IX_Orders_CreateDate. Единственное - в последнее время пришел к выводу, что следует отдельно обозначать индекс, накладываемый вместе с внешним ключом - потом в скриптах меньше путаницы получается. На данный момент остановился на префиксе FX_.
Внешний ключ: FK_%ParentTable%_%ChildTable%?Number? - такую или очень похожую схему предлагает по умолчанию большинство CASE-средств, и что-либо добавить к ней сложно - FK_Currencies_Payments2. Имена полей не включаю, т.к. в сиквеле тип sysname весит 128 символов максимум, и если выписывать все подряд, то можно очень быстро доиграться.
Триггер: trg_%TableName%_%TriggeredStatement%. Но обычно не заморачиваюсь - все равно это имя только в DDL-скриптах встречается.

Если я забыл что-то из стандартных типов объектов, значит, меня их имена мало волнуют - если сходу не вспомнил... А теперь - кое-что специфичное:
Пользовательская роль: %префикс%_%основная привилегия%. В данном случае префикс также является неким неймспейсом, но обычно в более широком смысле, нежели в случае хранимых процедур - скажем, accounting_paymentsviewer. Правда, вопросом именования ролей в моем случае обычно занимается начальство, так что тут все тоже весьма зыбко и крайне специфично к конкретному применению.


Ну, вроде как все. Да, еще одно - сокращений в именах не приемлю ни в какой виде, ибо при иерархии хотя бы в 5 уровней такой внешний ключ обычно напоминает бред сумасшедшей машинистки.

[gaidar]

Мое именование:

Таблица: Users
Поля: ID Login Password Type
Таблица: Moderators
Поля: UserID ForumID

При написании запросов без использования псевдонимов, убивать надо! Если серьезно, то у меня всегда требование к коду - импользование alias'ов для таблиц.

Код: Выделить всё

SELECT U.Login, F.Title FROM Users U
INNER JOIN Moderators M ON M.UserID = U.ID
INNER JOIN Forums F ON F.ID = M.ForumID
WHERE Type = @Type

[skiperski]

Я имел в виду псевдонимы не таблиц, а полей. Например, есть две таблицы

Код: Выделить всё

Users (Id, Name)
Documents (Id, Name, Owner)

Связываем их в запросе, если поля явно не определены

Код: Выделить всё

SELECT d.*, u.*
FROM Documents d
    INNER JOIN Users u ON u.Id = d.Owner

, то что будут в этом случае выдавать rs!Id и rs!Name не известно.

Если же перечислять все поля, то придётся давать алиасы полям с совпадающими именами

Код: Выделить всё

SELECT d.Id AS DocId, d.Name AS DocName, u.Id AS UserId, u.Name AS UserName
FROM Documents d
    INNER JOIN Users u ON u.Id = d.Owner

Тогда уж лучше правильно поименовать их сразу же при проектировании таблиц.

Проблема в том, что у многих таблиц целое семейство совпадающих имён полей: Id, Name, Description, Comment, Owner, CreateDate и т.д. И, если UserId или UserName ещё как-то звучат или просто привычны, то UserDescription, UserCreateDate, DocumentComment или DocumentOwner выглядят как-то нелепо и громоздко. А если имя таблицы ещё длиннее или состоит из двух слов и само поле из двух, то получаются такие кракозяблы, что просто залюбуешься: UserGroupsMembersPermissionId. Мне и интересно кто и как выходит из подобных ситуаций.

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

[GSerg]

Как-то смотрел я внутрь забугорной базы, обслуживающей ихний аналог 1С.

Таблицы имеют осмысленные названия средней длины с вехнем регистре. К примеру, таблица SALES_LEDGER. Все поля каждой таблицы (за исключением, возможно, первичного ключа, не используемого нигде, т.к. для связывания записей используется всегда другое поле с уникальным индексом и с человекочитаемым контентом) имеют название по форме ПРЕФИКС_ИМЯ, где ПРЕФИКС есть прямая аббревиатура названия таблицы, а именно первые буквы составляющих слов. Для SALES_LEDGER префикс SL. SL_ACCOUNT - одно из полей этой таблицы.
Таблиц там больше 250. Благодаря этой фишке все имена всех полей разные. И сразу видно, к какой таблице они принадлежат - ибо, по странному стечению обстоятельств, я привык давать таблицам в запросе alias'ы именно по аббревиатурам - SALES_LEDGER AS sl. Теперь можно и не давать, читаемость не нарушается.

[alibek]

Верхний регистр -- это просто перестраховка от всяких тонкостей дата-провайдеров. Скажем, кривой провайдер под DBF различает регистр и там могут быть проблемы в ссылках на поля. Поэтому всегда использовать верхний регистр безопаснее.
Вариант Ennor-а тоже довольно распространен, у него есть свои плюсы и свои минусы (по сравнению с той схемой, которую использую я). Так что выбирать лучше то, что привычнее самому.

[Andrey Fedorov]

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

Скорей всего тяжкое наследие DOS-овских баз - таблицы просто перетащили на SQL... Имена полей/таблиц остались старые.

[alibek]

Не, БД изначально была оракловской.

[Andrey Fedorov]

Не, БД изначально была оракловской.

Значит программист который ее делал незадолго до этого работал с DOS-ом. Ноги верхнего регистра как правило растут оттуда...

[Konst_One]

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

Table1 и table1 - это разные таблицы могут быть в одной схеме

[alibek]

Не, программисты тоже толковые
http://www.billing.ru/

[Ennor]

Не, программисты тоже толковые
http://www.billing.ru/

Махровая системка, должно быть. Да и коллективчик наверняка тот еще - небось, еще с Адабасом работали...

[Ennor]

DocumentComment

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

В самом крайнем случае я использую схему %ObjectAlias%_%FieldName% - она, по крайней мере, гарантирует уникальность в пределах запроса. Но это действительно редкость, и как правило это не рабочий код, а всякие вьюхи для облегчения администрирования - есть у меня несколько таких, блокировки разруливать...

[skiperski]

Как-то смотрел я внутрь забугорной базы, обслуживающей ихний аналог 1С.
...

Вот это уже какой-то осмысленный и мотивированный подход. Только, мне кажется, двух символов будет не достаточно для создания осмысленных префиксов. Даже не знаю как они умудрились сделать их аж 250 штук не повторяющихся и несущих смысловую нагрузку. Интересно как они поступали с таблицами типа GROUP_MANAGERS и GROUP_MEMBERS или заранее проектировали названия таблиц с неповторяющимися первыми буквами?

DocumentComment

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

Я такие префиксы обыкновенно даю только ключевым полям. Дополнинтельные (Comment, Owner и т.п.) по неосознанной пока причине пишу в простом виде. Вот и пытаюсь осознать почему так происходит. Видимо, ключевые поля часто пересекаются в запросах, а дополнительные требуются только для каждого объекта по отдельности. Потому на интуитивном уровне делаю так. Надо этот интуитивный подход выразить как-то формально.

[alibek]

Махровая системка, должно быть. Да и коллективчик наверняка тот еще - небось, еще с Адабасом работали...

Не, система хорошая
И работала хорошо, и спроектирована грамотно, практически самодокументированная система.
Вот доводилось видеть систему от НПФ Беркут, вот это ужас. По сравнению с Питер-Сервисом -- стадо пионеров-энтузиастов делали систему и каким-то непостижимым способом заставили ее работать.
Доводилось видеть сильно издали буржуйскую биллинговую систему, это вообще страх ходячий.

[Andrey Fedorov]

Интересно как они поступали с таблицами типа GROUP_MANAGERS и GROUP_MEMBERS или заранее проектировали названия таблиц с неповторяющимися первыми буквами?

Что касается названия таблиц - глянь на приложенный снимок - там базка от MS.

HumanResources - схема
Department - таблица

А вместе HumanResources.Department

[Andrey Fedorov]

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

А что удивительного - у них тоже пионеры есть (в том числе и наши).

[alibek]

Нееее! Там не пионеры, там динозавры

[skiperski]

А вместе HumanResources.Department

Если бы это только для чтения, то было бы не страшно так называть. Хоть целыми предложениями, но ведь ещё и запросы с этими именами потом писать нужно будет.

[Konst_One]

ну так на чиста аглицком и будешь чиркать эти запросы