|
|
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
ТриггерманPAPA_RimskY, 1. Все названия объектов только буквами английского алфавита. 2. Все названия объектов на английском языке. 3. Для каждого типа объекта свой префикс и знак "подчёркивания" Например, таблица - T_ вьюха - V_ процедура - P_ функция - F_ первичный ключ - PK_ внешний ключ - FK_ индекс - IX_ Возможно, таблицам префиксы, о том что это таблица не нужны в РМД. Так как таблицы это собственно основное в БД - средство структурирования данных (БД - это прежде всего информация). И их имена могли бы иметь только намек на содержание данных таблицы. А для подчеркивания роли "справочника", возможно, в имя добавлять подслово TYPE. Т.е. нацелить именование именно на упрощение содержательно понимания схемы БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2014, 14:32 |
|
||
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
>1. Как именуете таблицы связи many-to-many? В приоритете - по смыслу. Лучше указать смысл связи в имени (часто такая таблица - полноценная сущность), это важнее того, какие именно сущности связываются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2014, 17:52 |
|
||
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
Гхостик>1. Как именуете таблицы связи many-to-many? В приоритете - по смыслу. Лучше указать смысл связи в имени (часто такая таблица - полноценная сущность), это важнее того, какие именно сущности связываются. Такая таблица вполне может может быть "полноценной" связью (в ней собсно присутствуют атрибуты по которым связь). Потому чтобы это сразу бросалось в глаза, можно как-то указать это в имени. Например, по три буквы от каждой таблы (или идентификаторов по котором идет связь), а межу подчеркивание. Глядя на схему это сразу подскажет что речь идет о связи многие ко многим. Но так или иначе выделить. Там где работаю принято: у каждого атрибута всегда суффикс из трех букв таблы. Это тоже как-то упрощает: сразу видна разница между родными и мигрированными атрибутами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2014, 18:36 |
|
||
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
WebSharperв имена полей не включаю никаких префиксов (Не ElefantID, а просто ID) а в название полей входящих в FK, если это единственное поле, не включаю названия PK (не MotherID, а просто Mother) . Я выработал противоположную практику. Все поля снабжаю префиксом -- 2--4 буквенным сокращением имени таблицы. Поле, входящее в FK, называю префиксом от таблицы-источника. Так, если таблица Elefant ссылается на таблицу Mother, то: id в таблице Mother получит название MOTH_ID, и в таблице Elefant поле - ссылка на Mother получит то же имя MOTH_ID. Чем удобно -- конструируя SQL-запросы с джойнами можно будет обойтись краткой записью «from T1 natural join T2» вместо «T1 join T2 on (длинная формулировка условия)». ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2014, 12:52 |
|
||
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
Владимир П.Все поля снабжаю префиксом -- 2--4 буквенным сокращением имени таблицы. Поле, входящее в FK, называю префиксом от таблицы-источника. Так, если таблица Elefant ссылается на таблицу Mother, то: id в таблице Mother получит название MOTH_ID, и в таблице Elefant поле - ссылка на Mother получит то же имя MOTH_ID. Чем удобно -- конструируя SQL-запросы с джойнами можно будет обойтись краткой записью «from T1 natural join T2» вместо «T1 join T2 on (длинная формулировка условия)». А давайте слон будет ссылаться на папу и маму - тоже слонов, как напишете запрос для показа имен слона, его мамы и папы? Мой вариант: Код: sql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2014, 13:02 |
|
||
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
ГхостикА давайте слон будет ссылаться на папу и маму Т.е. таблица ссылается сама на себя, формируя иерархическую связь? В подлобных случаях, конечно, трюк с natural join не выйдет, и мой запрос будет такой же по сути, как ваш. С учетом принятых правил именования: Код: sql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2014, 13:09 |
|
||
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
У Селко неплохо написано про принципы наименования. У него есть даже очень интересная мысль - заменить прификсы окончаниями. Этот прием очень неплохо себя показал в нормальных языках программирования, потому что сразу видно когда работают связанные по смыслу команды, а когда - нет. А информация о типе хоть и важна, но вторична по отношению к смысловой нагрузке. Вообще префикс - это наследие тех времен, когда программы придумывались долго, а набирали, например на перфокарту, быстро, да еще и компы могли быть разной архитектуры. Соответственно больше ошибок было при наборе. Сейчас другие реалии, быстро придумывают и долго набирают. Так долго, что даже begin и end некоторых отягощает просто непосильно. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2014, 08:51 |
|
||
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
Могу про нашу базу рассказать, она весьма большая и весьма старая. Таблицы называются в единственном числе, без префиксов и суффиксов Поля - аналогично PK может называться как угодно, но все FK обязаны называться так же, как и PK Названия индексов начинаются с IX_ Название вьюх начинается с префикса, подчеркивающего их *назначение*. У нас оракл, так что соглашений для хранимок нет, а пакеты начинаются с префикса PKG_ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2014, 09:12 |
|
||
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
scfPK может называться как угодно, но все FK обязаны называться так же, как и PK Это хорошее правило. Но оно не может быть столь категоричным. Просто потому что следовать ему не всегда возможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.10.2014, 18:02 |
|
||
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
scfPK может называться как угодно, но все FK обязаны называться так же, как и PK Названия индексов начинаются с IX_Как это, у нескольких констрейнов одинаковое имя??? Мы называем так: PK_ИмяТаблицы FK_ИмяТаблицы_ИмяТаблицы IX_ИмяТаблицы_ИенаПолей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2014, 09:49 |
|
||
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
Владимир П.Mother получит название MOTH_ID Люблю смотреть всякие сокращения и описки в словарях. Moth - это моль :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2014, 10:28 |
|
||
|
О нейминге, или как вы придумываете имена
|
|||
|---|---|---|---|
|
#18+
Таблицы - существительные без разделителей, CamelCase. Поля - Id, ParentEntityId. Вьюхи - зависит от случая: если просто прокси для таблицы с разыменованием справочников, то ViewTableName; если группирует неск. таблиц в отдельную сущность, то ViewThisEntityName. Вообще, не люблю подчеркивания. Процедуры - примерно как если бы это были методы объектов (коими их, при должном уровне абстракции, вполне можно считать). Сначала логическая подсистема, потом (опционально) уточнение, потом - название метода. Например: documents_create, security_user_update, workflow_document_changeowner. В сложносоставных частях делаю Camel, но чаще все имя в нижнем регистре. PK и FK - написал специальные скрипты для PowerDesigner, которые массово переименовывают соотв. объекты к видам PK_TableName и FK_ChildTable_ParentTable_ChildColumnList, соответственно. До этого был аналогичный скрипт на SQL, но лучше в консерватории править, как известно. Но иногда и в БД приходится переименовывать, если схема чужая и все вразнобой. Индексы - IX_TableName_ColumnList, но иногда бывает и короче. Если есть натуральный ключ, то UQ_TableName_NK. Иногда, если очень большой список столбцов, то приходится обрезать до 128 знаков (FK тоже касается). Т.е. правила есть, но без фанатизма (исключение - все на английском, в моем случае это обязательно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.10.2014, 12:24 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=38783728&tid=1540763]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 373ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...