 | | | | |
| Правила именования объектов базы данных |
Полный текст материала
Другие публикации автора: Алексей Михайличенко
Цитата или краткий комментарий: | «... Обсуждаемый вопрос заключается в следующем. Если мы начали разработку
базы данных для некоторой задачи, определились с набором
схем, таблиц, полей, внешних ключей, то как нам следует называть все
эти объекты, и зачем вообще нужно говорить о какой-то особой системе
наименований? ...» |
Важно:- Страница предназначена для обсуждения материала, его содержания, полезности, соответствия действительности и так далее. Смысл не в разборке, а в приближении к истине :о) и пользе для всех.
- Любые другие сообщения или вопросы, а так же личные эмоции в адрес авторов и полемика, не относящаяся к теме обсуждаемого материала, будут удаляться без предупреждения авторов, дабы не мешать жителям нормально общаться.
- При голосовании учитывайте уровень, на который расчитан материал. "Интересность и полезность" имеет смысл оценивать относительно того, кому именно предназначался материал.
- Размер одного сообщений не должен превышать 5К. Если Вам нужно сказать больше, сделайте это за два раза. Или, что в данной ситуации правильнее, напишите свою статью.
Всегда легче осудить сделанное, нежели сделать самому. Поэтому, пожалуйста, соблюдайте правила Королевства и уважайте друг друга.
Добавить свое мнение.
| | | Содержит полезные и(или) интересные сведения | | [1] | 3 | 42.9% | | | | | Ничего особенно нового и интересного | | [2] | 1 | 14.3% | | | | | Написано неверно (обязательно укажите почему) | | [3] | 3 | 42.9% | |
Всего проголосовали: 7 | | | | Все понятно, материал читается легко | | [1] | 4 | 66.7% | | | | | Есть неясности в изложении | | [2] | 2 | 33.3% | | | | | Непонятно написано, трудно читается | | [3] | 0 | 0% | |
Всего проголосовали: 6 |
[Моделирование БД]
Отслеживать это обсуждение 
Всего сообщений: 5122-04-2009 00:54| Статья обязательна к прочтению всем, кто начинает работать с БД, но строко с комментариями, т.к. изложенный материал на стандарт далеко не тянет (опять-таки субъективно, соотношение того, что стоит принять за "стандарт", и того, чего лучше не использовать - 50/50). Воспринимать стоит как объемный заголовок к теме на БП. |
|
03-09-2008 12:04Интересно. Два года назад я задал здесь вопрос и ответом на него стала эта статья, тогда я с автором согласен был почти на все 100%. Прошло два года и я уже данво сижу на C# и два года не заходил на королевство, а тут зашел - оп а ссылка на статью на первой странице!!! Тема актуальна досихпор. статью перечитал и понял что мои взгляды изменились и очень сильно!
1. Имена таблиц не такие кароткие как 3-4 символа, а нормальные в пределах разумного ну и почемуто в большенстве своем во множественном числе. (Emploees к примеру)
2. Имена атрибутов без префикса имени таблицы ID, Label, Size а если эт внешний ключ то StreetID - ключ на таблицу Streets по атрибуту ID
Ну как говорится - у любых правил есть исключения и они действительно бывают и их не надо бояться.
Нк и конечно нужно состовлять словарь терминов базы - помогает! |
|
02-09-2008 07:38
15-08-2008 03:09>>> поскольку раз уже в программе прописан SQL-запрос, то и порядок следования полей точно известен
Опасная штука. Программы имеют свойство развиваться. Так что запрос (прописанный например в TDataModule) Вы можете и поменять. И порядок полей при этом может поехать. При этом, если Вы даже измените имена полей (чего лучше не делать без особой нужды) то найти все места, которые нужно будет поправить, несколько проще, когда Вы обращаетесь к полю по имени.
К полю по номеру стараюсь обращаться только в запросах, типа
SELECT COUNT(*) FROM ...
Тут у нас одно единственное поле, которое никуда не денется. |
|
15-08-2008 03:00В статье местами перепутаны понятия "суффикс" и "префикс". Префикс - в начале, суффикс - в конце. :)
А что там за смысловой префикс, все эти -id, -name, -label, -area?
В именах полей таблицы я не использую имена сущностей, поскольку мне это кажется излишним, кроме того, без этого проще, мне кажется, работать с разными таблицами, имеющими одинаковую или сходную структуру.
По поводу
>> безнадежности задачи FieldByName()
замечу, что мне хватает использования
for i:=0 to Fields.Count-1 do
Fields[i].AsString;
поскольку раз уже в программе прописан SQL-запрос, то и порядок следования полей точно известен.
Поскольку для БД использование символов разного регистра не очень подходит, я для отделения префиксов использую символ подчёркивания. В коде Delphi - одно, а при работе с БД - другое.
А вот идея с префиксами в именовании таблиц мне понравилась, сам я почему-то не додумался.
Мой принцип именования полей таблицы:
id - первичный ключ
name - название
id_street, id_street_type - внешний ключ
(теперь, видимо, будет id_sstreet, id_cstreet_type или всё-таки id_s_street, id_c_street_type )
(комментарии ещё не читал, прошу прощения, если повторился) |
|
14-08-2008 06:29сообщение от автора материала К вопросу о важности темы. Кусочек реально работающего во многих организациях проекта:
IF xo_xo # space(8)
@ 22,24 say xo_xo color gr+/n
ENDIF
IF xa_xa # space(7)
@ 22,34 say xa_xa+"."+xi_xi color gr+/n
ENDIF
|
|
30-10-2007 10:01Случайно наткнулся на эту тему. Вот отрывок из статьи для ibase.ru, которую написал 30 июня 2006 г. (к сожалению, она так и не было опубликована).
1. Стандарт именования.
Все объекты именуются заглавными буквами.
Именами объектов могут являться только английские слова. "ADRES", "KVARTIRA", "NAIMENOVANIE" недопустимы.
Если имя состоит из нескольких слов, они разделяются символом "_".
Именование таблиц.
Имена таблиц состоят из трех частей: префикс, категория и имя таблицы. Все три части разделены символом "_". Это позволяет, просто глядя на таблицу, понять ее предназначение.
Префикс указывает функциональное назначение таблицы. Длина префикса - 3-4 символа (без учета "_").
Стандартные префиксы:
DIR - справочник (Directory);
SYS - системная таблица (System);
INF - информационная таблица (Information);
MAG - журнал (Magazine).
Длина категории - от 3-х символов. Допускаются сокращения.
Пример: "ADDRESS", "EQUIPMENT", "PRIVILEGE".
Имя таблицы уже указывает, что конкретно она хранит. В конце имени таблицы буква "S" не ставится. Допускается произвольное количество символов "_".
Пример: "CITY", "STREET", "MARK_STOVE".
Примеры полных имен:
"DIR_ADDRESS_CITY" - справочник городов.
"DIR_REPSRV_GAS_ANALIZATOR" - справочник газоанализаторов. Используется ремонтной службой.
"INF_EQUIP_STOVE" - информация о плитах. Оборудование.
"SYS_INF_OPERATOR" - системная информация об операторах.
Домены.
Имя домена начинается с префикса "D_".
Имя домена отражает только тип данных. Пример: D_BOOLEAN, D_MONEY, D_QUANTITY.
Запрещается создавать идентичные домены, которые отличаются лишь назначением. Пример неправильных имен: D_ID, D_KEY, D_INTEGER.
Поля.
Поля любой таблицы делятся на 3 категории:
- Поле первичного ключа. Имя всегда "ID".
- Поля внешних ключей. Перечисляются сразу после поля "ID" и сгруппированы по назначению.
Поле непосредственной мастер-таблицы идет первым. Имя состоит из префикса "ID_" и имени таблицы, на которую ссылается (без префикса и постфикса).
Если ссылок на таблицу несколько, к имени поля добавляется назначение поля.
- Поля данных. Группируются по назначению. Поле имени (если таковое есть), всегда "NAME". Допускаются префиксы и суффиксы.
Индексы.
Индекс первичного ключа всегда имеет имя "PK_ПОЛНОЕИМЯТАБЛИЦЫ".
Индекс внешнего ключа всегда имеет имя "FK_ПОЛНОЕИМЯТАБЛИЦЫ_ИМЯВНЕШНЕЙТАБЛИЦЫ". Имя внешней (внешнего ключа) таблицы без префикса и категории. Если имя слишком длинное, оно усекается ровно до максимально допустимых размеров.
Другие индексы именуются "IDX_ПОЛНОЕИМЯТАБЛИЦЫ_ПОЛЕ1[_ПОЛЕ2][_ПОЛЕ3]".
Генераторы.
Генераторы именуются следующим образом: "SEQ_ПОЛНОЕИМЯТАБЛИЦЫ_ID".
Триггеры.
Триггеры именуются так: "ПОЛНОЕИМЯТАБЛИЦЫ_[B|A][IUD]",
Где B|A - время срабатывания. B[efore] - перед, A[fter] - После действия.
IUD - тип действия. I[nsert] - вставка, U[pdate] - модицификация, D[elete] - удаления.
Если триггеров на одно время и тип несколько, к ним добавляется суффикс с порядком срабатывания.
В продолжение темы:
1. О необходимости прописывания альясов в случае соединения нескольких таблиц - 97% запросов программы генерируются автоматически, поэтому мне это фиолетово. Шаблон таков: "NAME_" + ИМЯТАБЛИЦЫ (NAME_CITY, NAME_MARK_STOVE и т.д.). А в тех, что используются в отчетах - копипаст всегда поможет :); а вообще про отчеты это отдельная тема.
2. Подчеркивание надо использовать, так как имена сущностей в SQL регистронечувствительны. Кстате, судя по тексту, Fisher использует сочетание верхнего и нижнего регистров в запросах. Внимание, вопрос: это корректно? Если нет, то ситуация с подчерками отпадает автоматом - они нужны. |
|
08-05-2007 09:02сообщение от автора материала Верно подмечено, в INSERT, UPDATE никаких коллизий при различных системах наименования не наблюдается. Почему - понятно: эти команды оперируют именами полей в контексте одной таблицы (за исключением возможности некоторых серверов работать с несколькими таблицами в UPDATE).
Верно также то, что я работаю скорее с OLAP-похожими системами. И хотя я не могу похвастаться особым опытом в создании OLTP-систем, но мне представлялось, что понятие "в бОльшей мере делает INSERT, UPDATE, DELETE" относится скорее к выполняемому количеству команд в единицу времени в реальном режиме работы, чем к количеству операторов в программном коде.
Грубо говоря, в тексте программы может быть на десяток INSERT - два SELECT-а, и это будет OLAP-система, если все это дергается медитирующим пользователем раз в минуту. А может быть одна команда INSERT и десяток SELECT, но это будет OLTP-система, если этот один INSERT крутится десять раз в секунду, собирая какую-то телеметрию.
Так что мне хотелось найти каке-то общие подходы, независимо от назначения системы.
|
|
08-05-2007 05:40прошлый пост не прошел
Типа, если слишком длинные названия у полей, то база данных не успеет отработать телеметрию с ракеты, как пример OLTP
Честно говоря я не понял с чего такой вывод?! :)
Ваш подход к именованию хорош если бОльшая часть выборок возвращает пересечения, объединения и прочие кубы. Это хорошо для OLAP - для БД, которая занимается, в основном анализом относительно статичных данных.
OLTP - в бОльшей мере делает insert,update,delete. Тогда напрягает писать
update MyTable set MyTable_LastName='Ivanov', MyTable_FirstName='Vasja', MyTable_sex='female' where MyTable_ID=1121
Вот и всё.
Разный опыт - разные мнения/убеждения
Всё это сугубо ИМХО
С уважением. |
|
04-05-2007 03:47сообщение от автора материала >>> за краткость - это в статье прямое требование
Читайте меня - там все написано ;-))
Выбор имени сущности
2. Имя должно быть как можно короче. Оптимально - 2-4 буквы, максимум до 10.
Наименование таблиц
Имя таблицы состоит из служебного префикса и имени сущности [т.е. всего один символ дописывается]
Наименование полей
...смысловой суффикс...минимальной длины и максимальной понятности...
>>> Мне кажется что Fisher больше с OLAP связан, а его противники с OLTP - подходы к именованию разные.
Ж8-() Можно поподробнее эту мысль? Типа, если слишком длинные названия у полей, то база данных не успеет отработать телеметрию с ракеты, как пример OLTP? ;-)
|
|
04-05-2007 03:23за краткость - это в статье прямое требование
я что-то упустил?
по-моему имя поля "TableName_FieldName" довольно длинное получается.
Мне кажется что Fisher больше с OLAP связан, а его противники с OLTP - подходы к именованию разные. |
|
03-05-2007 10:47сообщение от автора материала Мда. Спрашиваем, как будет выглядеть запрос, а нам - сколько лет методу, и легко ли ищется человек. Ну да ладно, это был непринципиальный вопрос.
А краткость названия и скалярность атрибута - вещи все же разные. Можно назвать кратко = "ADR", а впихнуть туда все сущности - от страны до квартиры. А можно цифирку разобозвать "amplitude_modulation_index".
Против скалярности никто не спорит, а за краткость - это в статье прямое требование. Рад, что в этом мы сходимся.
|
|
03-05-2007 08:15
to Fisher
Спасибо. Очень интересный подход к хранению адресных данных. Интересно, как будет выглядеть запрос "найти человека по адресу" (даны параметры: город, улица, дом, корпус, квартира)?
Этому подходу сто лет в обед, я его застал еще в эпоху становления (КЛАДР назывался).
Ищется человек легко :), особенно если адрес похож на
город Москва
деревня Южное Бутово
улица Красноармейцев
дом 5
строение 4,
т.е. иерархия уровней и их набор отличаются от остальных 10 млн москалей :)
Но это опять же не повод запихивать в название поля все буковки, которые знаете. Название атрибута должно быть коротким. Если оно составное - значит атрибут составной, т.е. форма ненормальная. |
|
03-05-2007 07:56to Fisher:
Хорошо, давай попробуем явно сормулировать все утверждения, а потом подумаем.
1. Требовать уникальности имен все полей всех таблиц (включая служебные таблицы) в рамках одной БД -- этоизлишнее ужесточение требований. Cоответственно, в запросах останется использование TableName.FieldName.
2. Для работы на физическом уровне форма записи TableName.FieldName удобнее, чем зашивать имя таблицы в префикс поля.
3. Для работы на клиенте удобнее форма записи TableName_FieldName.
4. Однако алиасы все равно писать придется. Например, для агрегатных функций.
5. Иногда может так оказаться, что название полученное формально объединением двух слов имеет устоявшееся название из одного слова (самка собаки ;-)), так что в этом случае тоже придется писать алиасы.
Мораль. Чтобы и невинность соблюсти и капиталл приобрести, пишем TableName.FieldName AS TableName_FieldName и не жужжим :-D |
|
03-05-2007 06:58сообщение от автора материала to pastor:
Спасибо. Очень интересный подход к хранению адресных данных. Интересно, как будет выглядеть запрос "найти человека по адресу" (даны параметры: город, улица, дом, корпус, квартира)?
to Geo:
А если использовать полное имя поля, то тогда как-то глупо писать TableName.TableName_FieldName (на фига указывать одно и то же два раза?). Если же тебе так важны алиасы полей, но лень прописывать их руками, то, вроде бы, СУБД все равно присваивает каждому составному полю автоматически сгенеренное название. Можно пользоваться им.
Автоматически сгенеренные названия неприемлемы, хотя бы потому, что они зависят от порядка перечисления полей в запросе - этого только не хватало. Придется прописывать их руками. И если вглядеться, то в общем случае получится что-то вроде
TableName.FieldName AS TableName_FieldName
Встречный вопрос: на фига указывать одно и то же два раза? ;-)
|
|
03-05-2007 02:26>>> И во-вторых, зачем вообще писать такой раздел и выполнять соответствующую процедуру присобачивания алиасов, если без нее можно обойтись, и поступить как я предложил?
Поясняю... Синтаксис SQL позволяет использовать имя поля с префиксом в виде имени таблицы (TableName.FieldName). Не знаю, кто как, но я уже на автомате использую полные имена полей (за исключением, разве что, самых простых запросов. Можно, конечно, добиться ввести требование уникальности имени каждого поля в базе, но, по-моему, это уже перебор: слишком много будет имен с незначащими (или малозначащими) префиксами. А если использовать полное имя поля, то тогда как-то глупо писать TableName.TableName_FieldName (на фига указывать одно и то же два раза?). Если же тебе так важны алиасы полей, но лень прописывать их руками, то, вроде бы, СУБД все равно присваивает каждому составному полю автоматически сгенеренное название. Можно пользоваться им. |
|
03-05-2007 00:35
>>> по поводу T_ - скажите, зачем оно Вам нужно? Разные пространства имен.
Верно, но у программиста голова - не компилятор, и современное программирование одобряет мнемоничность обозначений в разумных пределах, даже если это избыточно с точки зрения языка.
Таких не берут в программисты :) Нет смысла добавлять префиксы и мнемоники, если можно написать сразу все слово. NAME - уже тип.
А по поводу Вашего последнего замечания от комментариев воздержусь.
А напрасно.
select at.NAME ||' '|| av.NAME as "Строка адреса"
from ADDRESS_VALUES av
join ADDRESS_TYPES at on av.ID_AT = at.ID
where av.ID_PEOPLE = :PEOPLE
order by at.LEVEL
г. Москва
ул. Садовая
д. 302
корп. 2
кв. 50
Можно добавить по вкусу всякие coalesce, рассказать о нормализации и пр., но это будет уже другая история, в мае :) |
|
02-05-2007 12:56сообщение от автора материала to Geo:
>>> Я про сам принцип именования для работы в SQL. А какие там будут алиасы, это уже дело десятое.
Вот с этим-то я и борюсь. Мы ведь не только "работаем в SQL", но и еще клиентов, процедуры, отчеты пишем... И я не согласен, что алиасы - "дело десятое", потому что они без должного внимания окажутся разными в разных запросах. Следовательно, разными будут поля в клиентских DataSet-ах. И любая функциональность на клиенте и в отчетах будет завязана на этот зоопарк. К чему тогда супер-правильное именование объектов БД?
Я бы согласился с твоей точкой зрения, если бы мы сформулировали еще один пункт к статье - "правила образования алиасов при совпадении имен полей в запросе", и я остался бы доволен - вопрос формализован. Но такое решение показалось мне еще более громоздким, чем мое. Почему?
Во-первых, потому что получается, что один и тот же атрибут (например, название города) может явиться клиенту либо как NAME, либо как CITY_NAME, в зависимости от того, оказались ли в запросе другие NAME или нет. А если сначала их не было, а при модификации запроса появилось - переименовывать существующие поля? Это плохо.
И во-вторых, зачем вообще писать такой раздел и выполнять соответствующую процедуру присобачивания алиасов, если без нее можно обойтись, и поступить как я предложил?
to pastor:
>>> по поводу T_ - скажите, зачем оно Вам нужно? Разные пространства имен.
Верно, но у программиста голова - не компилятор, и современное программирование одобряет мнемоничность обозначений в разумных пределах, даже если это избыточно с точки зрения языка.
А по поводу Вашего последнего замечания от комментариев воздержусь. |
|
02-05-2007 08:13
to Fisher
>>> Статья действительно вредная.
Поверьте, автор действительно еще вреднее, и теперь Вам от него так просто не отделаться ;-)
Вы затронули другой вопрос - единообразное задание типов и размерностей не в каждой таблице, а через домены. В статье я этого не касался, но раз уж зашла речь - я согласен на 100%, что это замечательно.
Но уж по поводу именования, я бы дал доменам имена вроде T_NAME, T_CAPTION, и говорил бы
DEVNAME T_NAME
DEVCAPTION T_CAPTION
по поводу T_ - скажите, зачем оно Вам нужно? Разные пространства имен.
А если Вы все NAME называете NAME, изложите свой взгляд на обсуждающийся тут запрос по выводу "г." "Москва" "ул." "Ленина".
Вы как китайские пионеры, придумываете себе трудности и мужественно их преодолеваете. У меня нет таких проблем - я показываю пользователю только русские буквы. Мне достаточно одного слоя метаданных. Есть на свете другие подходы - со вторым слоем (p.ex. Тенцер).
|
|
02-05-2007 07:39>>> Для меня остается загадкой: а что, на клиенте обращаться к полям по именам не нужно? Может быть, все-таки имеется в виду что-то вроде <...>
Ну, можно и так. Я про сам принцип именования для работы в SQL. А какие там будут алиасы, это уже дело десятое. Пусть будет даже "Наименования города", если СУБД позволит ;-) |
|
02-05-2007 07:14сообщение от автора материала to Geo:
SELECT CityTypes.Name,Cities.Name,StreetTypes.Name,Streets.Name FROM ...
Для меня остается загадкой: а что, на клиенте обращаться к полям по именам не нужно? Может быть, все-таки имеется в виду что-то вроде
SELECT
CityTypes.Name AS CityTypes_Name,
Cities.Name AS Cities_Name,
StreetTypes.Name AS StreetTypes_Name,
Streets.Name AS Streets_Name
FROM...
Так?
to pastor:
>>> Статья действительно вредная.
Поверьте, автор действительно еще вреднее, и теперь Вам от него так просто не отделаться ;-)
Вы затронули другой вопрос - единообразное задание типов и размерностей не в каждой таблице, а через домены. В статье я этого не касался, но раз уж зашла речь - я согласен на 100%, что это замечательно.
Но уж по поводу именования, я бы дал доменам имена вроде T_NAME, T_CAPTION, и говорил бы
DEVNAME T_NAME
DEVCAPTION T_CAPTION
А если Вы все NAME называете NAME, изложите свой взгляд на обсуждающийся тут запрос по выводу "г." "Москва" "ул." "Ленина".
|
|
02-05-2007 06:432 pastor
NAME NAME,
CAPTION CAPTION,
COMMENT COMMENT
а чем это хорошо? (что "имя переменной" совпадает с именем типа) |
|
02-05-2007 06:10Статья действительно вредная.
У нас сейчас 3 проекта примерно по 300 табличек. Проектам уже по 10 лет, и ес-но части писались разными людьми в разное время, так вот те места где написано:
DEVID
DEVNAME
DEVCLASS
и пр. в процессе естественного отбора выжжены каленым железом.
Теперь выглядит так:
create domain PK integer not null;
create domain FK integer not null;
create domain NAME varchar(100) not null;
create domain CAPTION varchar(200) not null;
create domain COMMENT varchar(1024);
create table XXXX (
ID PK,
ID_Y FK,
NAME NAME,
CAPTION CAPTION,
COMMENT COMMENT,
constraint XXXX
primary key(ID),
constraint XXXX_Y
foreign key (ID_Y) references YYYY(ID)
)
чего и Вам желаю.
|
|
02-05-2007 05:53>>>Ужасная статья, солидарен с ZeroDivide
не надо быть столь категоричным
ИМХО, любая система лучше чем отсутствие какой бы то бы было.
Fisher привел свое видение, ну и отлично. Он тоже прав . Есть сермяга в его словах.
PS
а представляете если бы тут схлестнулись мнения:
"программировать можно только с помощью goto & if"
"программировать нужно только с помощь while"
|
|
02-05-2007 05:35>>> Ну почему все поклонники этой методики деликатно обходят вопрос, как они выводят <...>
Коллега! У тебя что-то с память слабовать ;-)
Я же сразу написал вариант:
SELECT CityTypes.Name,Cities.Name,StreetTypes.Name,Streets.Name FROM ... |
|
02-05-2007 05:06сообщение от автора материала >>> Вот такой я злой сегодня. Кошмарная статья.
Не стреляйте в поэта по пьяни,
Не поняв его тонкую душу.
Ведь придется потом вам в бурьяне
Хоронить мою толстую тушу...
Знаете, я не могу сказать, что положения этой статьи вызывают у меня самого удовлетворение и нирвану. Но я знаю, что времена романтического проектирования баз данных, когда автор буквально любил каждую табличку, прошли. И там, где при проектировании не была применена достаточная степень формализации - в дальнешем тратится уйма времени и сил на элементарные вещи. И статья - попытка формализации. И подход "давайте в БД назовем все попроще и покороче, а потом над каждым запросом будем внимательно думать, как назвать выходные поля, а потом в клиенте думать, как назвали поля в этом запросе" - меня не устраивает.
Перефразируя известный лозунг, сформулирую главную задачу моего подхода: "Названо однажды - используется везде".
|
|
02-05-2007 04:50сообщение от автора материала >>> 2. Если есть наименование, называем поле NAME
Ну почему все поклонники этой методики деликатно обходят вопрос, как они выводят "г." "Москва" "ул." "Ленина", если здесь пересечены четыре сущности (тип населенного пункта, населенный пункт, тип улицы, улица), и у каждой сущности есть NAME? Не лень лепить четыре AS в каждом запросе?
|
|
02-05-2007 04:49Ужасная статья, солидарен с ZeroDivide. Удалите ее, и чем быстрее, тем лучше.
Или есть еще два варианта: переименовать в "Как не нужно называть таблицы и поля в БД", и второй - каждое предложение начинать со слов IMHO.
Вот такой я злой сегодня. Кошмарная статья. А ведь многие за год ее прочитали и приняли к сведению... |
|
02-05-2007 02:04Стандартизировать надо, ага.
Я именую всё (ну почти всё :)) по ангицки. Таблиы - имя сущности во множественном числе
Мне ближе позиция ZeroDivide. Т.е. я не включаю в название поля имя таблицы - масло-масляное
Расскажу, как я именую (см. список ZeroDivide)
1. Не связаный с данными, уникальный числовой идентификатор записи, значения которого генерируются средствами БД, обеспечивая уникальность, первичный ключ - p_XXXX, где XXXX - имя сущности
2. Если есть наименование, называем поле NAME, у меня есть детали - PARTS в ней PART-№ детали
3. Если есть описание, называем поле DESCRIPTION
4. Если есть даты жизни "Дата с" и "Дата по", то называем поля DATE_FROM и DATE_TO - не было такого
5. Для деревяшки - PARENT_ID - не было такого, как бы я назвал пока не придумал
6. Внешние ключи: как и первичные
7. Во всех остальных случаях называем поля в соответствии с следующими правилами:
а) Максимально точный перевод с английкого
б) Если слишком длинное > 32 символов, можно сократить, а ещё стараюсь, но редко,
использовать "известные" сокращения - qty, grp. (Вообще есть такое правило: если надо сократить
выкини гласные, посмотри, если нечитабельно, то используй наиболее, так сказать,
звонкие буквы для этого слова)
в) Разумеется, в единственном числе.
г) Слова в верхнем регистре, разделитель слов "_" - например, ORACLE переводит всё в верхний регистр
8. Констрейнты - "FK_" + TABLE_NAME_FROM + "_ON_" + TABLE_NAME_TO - именно так
9. Триггеры - "TR_BI_", "TR_BU_", "TR_BD_"... т.е. (B - Before, А - After; Триггер на все события "после", будет выглядеть так - "TR_AIUD_") - "TR_" не ставлю
10. Пакеты - "PKG_" + имя пакета. - да
11. Генераторы последовательностей (Сиквенсы) - "SEQ_" - сипользую "SQ_"
По поводу русских слов по английски
я так полагаю: сел программировать - учи английский
а то смешные случаи бывали:
- verstak - "вершина стека". Человек учил французский. Дело было на 1-м курсе
- glist - group list. Имя файла в ДОС-е
- shit - угадайте, что автор имел в виду :)
|
|
02-06-2006 02:52сообщение от автора материала Замечание вдогонку.
Наконец-то достал вот эту книжку: "Стиль программирования Джо Селко на SQL" http://delphikingdom.com/asp/book.asp?BookID=256
Посвящена, в частности, обсуждавшемуся здесь вопросу, и читается захватывающе. Содержит неожиданные взгляды по многим вопросам, а также поднимает кучу других неожиданных вопросов. Хотя стиль ее скорее эклектичный чем академичный, и местами читается трудновато (с переводом явные трудности, впрочем, думаю, адекватно перевести ее практически невозможно) - но все равно всячески рекомендую ее интересующимся темой именования, структурирования и стандартизации нашего труда.
|
|
18-05-2006 12:43| Статья дельная. От себя бы добавил, что для читабельности можно "метить" смысловые сокращения в названиях полей верхним регистром. Например: StrID вместо strid (особенно, если таблица названа что-то типа TblStr или Tbl_Str). Согласитесь, удобнее. |
|
12-05-2006 03:46сообщение от автора материала Не напрасны были мои страдания - наконец-то обнародованы еще одни правила! ;-))) По крайнем мере, есть из чего выбирать.
Сначала один мелкий вопрос:
6. Внешние ключи: имя внешней таблицы + "_ID" (EXTERNAL_TABLE_NAME_ID)
8. Констрейнты - "FK_" + TABLE_NAME_FROM + "_ON_" + TABLE_NAME_TO
Какие будут названия в ситуации двух ссылок на один справочник (пример с вектором и точками в статье)?
Теперь следующий:
Никакой неизбежности и select field as field_alias, для полей со стандартными названиями - это отличное решение.
select gds.name gas_distributing_station_name from gas_distributing_station gds
В чем проблема-то? Трудно написать? По моему каждый раз писать в названии полей
gas_distributing_station_name, во-первых не проще...
Вот здесь, видимо, мы и столкнулись лбами. Я считаю, что если уж поле становится известным "городу и миру" ( то есть абсолютно всей прикладной обвязке и прикладным программистам) под полным именем (AS gas_distributing_station_name), то нет совершенно никакой причины держать в БД иное название (name). В том-то и дело, что SELECT AS xxx мы пишем *каждый раз*, а CREATE TABLE - *раз и навсегда*, и AS становится ненужным.
...во-вторых - выглядит, просто идиотски
gas_distributing_station
(gas_distributing_station_some_field_1,
gas_distributing_station_some_field1_2,
gas_distributing_station_some_field1_3,
gas_distributing_station_some_field1_4)
Пример красноречив и ужасающ, но это всего лишь следствие частичного смешения двух идеологий. Ведь я-то, перед тем как совать имя сущности в каждое поле, прокричал на каждом углу, что его нужно сократить ;-) В итоге у меня это выглядит не столь ужасно:
CREATE TABLE sgrp (
grpid,
grmnum,
grpname,
grpnotes
)
Поэтому предлагаю обсуждение этого пункта завершить, остановившись на том, что мы полностью высказали и уточнили свои разногласия. Кому интересно - разберется и составит свое мнение.
Не знаю... почему для вас это не очевидно? Удивляюсь! Вроде, взрослый человек. И опыта, должно быть, поболе моего... и "желтые штаны" напротив ника :)
Жизнь научила меня одному важному правилу: хочешь чему-нибудь
научиться, не бойся признаться в своем невежестве. Скажи прямо: "Не знаю",--
и тотчас все бросятся тебе объяснять и показывать и в два счета тебя
просветят. И теперь я применил этот же принцип.
-- Что такое кривоклюв ? -- спросил я.
От такого невежества круглые голубые глаза Брайена округлились еще
больше, но он был слишком воспитан, чтобы высказать вслух то, что думал.
Дж.Даррелл. "Путь кенгуренка"
то статья вызвала у меня негодование... ее ведь будут читать и учиться по ней бегинерзы!
Думаю, учиться они будут все же по обсуждению. Ведь...
"Эпилог всегда любопытнее пролога"
Одиссей. "Троя"
|
|
11-05-2006 13:17Что-то с цитатами в последнем посте глюкануло...
А что мало конкретных рекомендаций - уже неоднократно говорили, что собственно в правилах наименования никаких преимуществ нет. Важно, чтобы эти правила были.
Согласен. Так что - консенсус... почти... стандарта-то все же нет и в этом проблема.
PS: И все же, еще пару копеек... View, превращающая name в street_name, решит вашу проблему :)
и для "имени" человека... вьющки легко сделают "имя работника", "имя пенсионера", "имя больного"... и даже "имя находящегося в отпуске по уходу за ребенком в местности, приравниваемой к районам крайнего севера, водолаза" :)
(У водолазов рассчет стажа идет по часам... всю парадигму портят - к@злы :) У нас в организации ни одного водолаза нет, но если устроится на работу... придется много править, ну или "костыль" специально для него прикрутить(чего я всегда стараюсь избегать)) |
|
11-05-2006 12:52Другими словами, если у "улицы" имеется атрибут "название улицы", то хотелось бы, чтобы имели одинаковое название:
У "улицы" имеется аттрибут "название", а не "название улицы"
А отсюда следует, что имена сущностей должны быть покороче. Не скрою, разумеется, у меня на практике они длиннее 2-4 символов, некоторые бывают и по 16.
У меня на практике - 20-25 в среднем. Зато, всем моим коллегам, понятно, без дополнительных разъяснений, что должно быть в поле, если я еще туда "привинчу" имя таблицы, то 50 символов в среднем - меня не устроит. А сокращать, в ущерб понятности, я тоже не хочу.
Кстати, оппонент игнорировал мой вопрос относительно ЖЭУ ;-)
:))) Да.. :) Проигнорировал... честно, не знаю, как назвать. Но считаю, что вопрос о наименовании поля - это тот вопрос, над которым можно продумать день... а может и переименовать поле уже в рабочей схеме (со всеми вытекающеми), если появится более правильное, отражающее суть или все-таки найдется точный перевод. Лично я, в своей практике, в сложных и спорных ситуациях, спрашиваю у носителей языка или у профессиональных переводчиков.
оставшиеся 20% - сокращения вроде k13, который символизирует "коэффициент надбавки стоимости за отопление сверхплощади"
Рискну предположить, что дело в недостаточной нормализации, т.к. в результате у вас должно остаться только "коэффициент надбавки"... а сверхплощади могли бы быть вынесены в отдельную сущность. Вполне вероятно, что в последствии еще придется учитывать и расчитывать что-нибудь и делать отчеты по этим сверхплощадям :) Либо же в отдельную сущьность надо было вынести коэффициенты надбавки. В таблице "коэффициенты надбавки стоимости" поле "отопление сверхплощади". (Сразу предупреждаю: на тему нормализации/денормализации спорить не буду - отдельная тема)
Разумеется, если от всей этой "Задачи Номер Один" отказаться, то можно придумать куда более изящные и экономные правила именования объектов базы данных. Но тогда для именования всего остального придется выдумывать свои правила.
Думаю, все же стоит отказаться. Т.к. не стоит "закладываться" на возможные select'ы и клиентские интерфейсы. Все таки базу нужно проектировать исходя только из соображений постоения реляционных отношений данных и оптимизировать стандарты наименований тоже. На этапе проектирования возможные пересечения предетных областей проследить тяжело, иногда даже не возможно. Когда ваш коллега будет писать приложение использующее и вносящее данные в вашу БД, то возможно... ваш маленький справочник улиц превратится в полный КЛАДР. Ваши "имя работника" из таблицы "работники" из "кадровой задачи", для "мед учета" превратится в "имя больного" или "имя пенсионера", для подачи данных в пенсионный фонд.
Не знаю... почему для вас это не очевидно? Удивляюсь! Вроде, взрослый человек. И опыта, должно быть, поболе моего... и "желтые штаны" напротив ника :)
PS: Не воспринимайте мои посты как наезд. Я все таки старался обосновывать свою позицию конструктивно. Может иногда жестко, но это только потому, что статья вызвала у меня негодование... ее ведь будут читать и учиться по ней бегинерзы! |
|
11-05-2006 12:52Прежде всего, почему-то большинство собеседников кинулись в технические детали, и прошли мимо Задачи Номер Один: "Единство именования программных единиц во всем проекте" (третий абзац статьи). Если кто-то считает это ненужным, то дальнейшие подробности об англоязычности и сокращенности теряют смысл.
Никто об этом не говорит, т.к. все понятно, что "Единство именования" нужно и оно есть, просто у всех компаний, занимающихся разработкой БД, свои корпоративные стандарты, выработанные с годами... и взятые тоже, между прочим, не с потолка.
Идея заключаеся в том, чтобы поддерживать единство именования всех этих... вещей во всех слоях проекта. Другими словами, если у "улицы" имеется атрибут "название улицы", то хотелось бы, чтобы имели одинаковое название:
2.1 - поле БД "название улицы"
2.2 - поле результата *любого* SQL-запроса, содержащего "название улицы"
2.3 - соответствующее поле всех клиентских наборов данных, как для ссылок из DBAware-компонентов, так и для программного обращения FieldByName
2.4 - локальные переменные, свойства классов, используемые в процедурах (именно здесь множественное число начнет резать глаза)
2.5 - начинка отчетов (независимо от технологии приготовления).
Идея... для многих, имхо, не нова. Но, повторяюсь, в том виде, в котором вы ее преподнесли - она выглядит плохо. Попытаюсь, все таки, объяснить... а заодно и рассказать о тех стандартах которые используем в разработке мы:
Итак:
1. Не связаный с данными, уникальный числовой идентификатор записи, значения которого генерируются средствами БД, обеспечивая уникальность, первичный ключ - всегда называтся ID
2. Если есть наименование, называем поле NAME
3. Если есть описание, называем поле DESCRIPTION
4. Если есть даты жизни "Дата с" и "Дата по", то называем поля DATE_FROM и DATE_TO
5. Для деревяшки - PARENT_ID
6. Внешние ключи: имя внешней таблицы + "_ID" (EXTERNAL_TABLE_NAME_ID)
7. Во всех остальных случаях называем поля в соответствии с следующими правилами:
а) Максимально точный перевод с английкого
б) Если слишком длинное > 32 символов, можно сократить.
в) Разумеется, в единственном числе.
г) Слова в верхнем регистре, разделитель слов "_"
8. Констрейнты - "FK_" + TABLE_NAME_FROM + "_ON_" + TABLE_NAME_TO
9. Триггеры - "TR_BI_", "TR_BU_", "TR_BD_"... т.е. (B - Before, А - After; Триггер на все события "после", будет выглядеть так - "TR_AIUD_")
10. Пакеты - "PKG_" + имя пакета.
11. Генераторы последовательностей (Сиквенсы) - "SEQ_"
(...Может чего и забыл написать)
Теперь, вернемся к Вашим "баранам" :)
Какое же должен быть принцип наименования полей БД в этом случае? Приходим к неизбежности включения имени сущности в имя поля. Иначе нам придется делать это через SELECT AS..., бессистемно, каждый раз размышляя, как бы назвать gas_distributing_station.name, если в запросе, оказывается, уже был city.name или gas_distributing_station_boss.name ;-)
Никакой неизбежности и select field as field_alias, для полей со стандартными названиями - это отличное решение.
select gds.name gas_distributing_station_name from gas_distributing_station gds
В чем проблема-то? Трудно написать? По моему каждый раз писать в названии полей
gas_distributing_station_name, во-первых не проще, во-вторых - выглядит, просто идиотски
gas_distributing_station
(gas_distributing_station_some_field_1,
gas_distributing_station_some_field1_2,
gas_distributing_station_some_field1_3,
gas_distributing_station_some_field1_4)
|
|
11-05-2006 07:31сообщение от автора материала Imho, это не конструктивные отличия.
Давайте я отвечу так: я не хочу вникать в механизмы реализации деревьев, поскольку об этом была отдельная статья. Не хочу также убеждать Вас в необходимости времязависимости данных и вариантах ее реализации, если в Вашей задаче они не нужны. Все это далеко выходит за рамки обсуждаемой темы. По именованию же ответ очень простой: если Вы не видите необходимости разделять 'C' и 'S', а также иные типы таблиц по их формальному назначению, используйте для них один и тот же префикс. Хотите разделять по иному принципу - используйте иные префиксы.
Цитировать эпиграф статьи не буду. Хочется большей четкости в определениях.
Тогда дайте четкое определение "конструктивности отличия" ;-)) А лучше - просто свои правила названий. Впрочем, четкость определений не имеет смысла, пока не обсуждена и не одобрена основная цель работы.
PS. Вот к чему-чему, а к эпиграфам еще никто не придирался! Услышал я его от уважаемого академика Крылова, которого я упоминал в предыдущей статье. Если хотите, оригинальный контекст:
http://v2.anekdot.ru/an/an9804/o980429.html#8
;-))
|
|
11-05-2006 06:141.
А префиксы, еще раз говорю - пожалуйста, дополняйте какие хотите
Имя таблицы состоит из служебного префикса и имени сущности.
Я, вообще, когда это читал, предполагал, что служебный префикс и имя сущности -
необходимые и достаточные элементы наименования таблицы. Оказывается, только необходимые.
2.
>>Можно ткнуть пальцем место в статье, где описываются конструктивные отличия каталога и справочника?
> S - Справочник. [...] Могут требовать инкрементального поиска, времязависимости, древовидных показов и чего угодно.
Imho, это не конструктивные отличия. Это отличия по вариантам использования. которые могут очень сильно меняться при изменении требований заказчика.
Хоть убейте, все равно различиия между каталогом и справочником продолжают казаться очень нечеткими.
У нас для выбора из датасета используется унифицированный интерфейс,
в котором по умолчанию есть инкрементальный поиск.
Когда в "каталоге" 5-10 записей, этот поиск не используется -
и так мышкой можно кликнуть и выбрать. За 10 лет эксплуатации системы в некоторых "каталогах" накопилось записей на 2-3 страницы в гриде, и инкрементальный поиск стал действительно нужен.
Это что же, "каталоги" стали "справочниками"?
и чего угодно.
5+
Цитировать эпиграф статьи не буду. Хочется большей четкости в определениях.
3.
Реализация древовидности и времязависимости предполагает добавление служебных полей(
Не понял фразу. Что такое "реализация времязависимости" и как она предполагает добавление служебных полей?
4.
А сокращения префиксов у вас в правилах именования - транслит или первая буква от английского перевода?
каталог => сокращение "C" (Catalog?)
регистр => сокращение "R" (Roll?, Register?)
журнал => сокращение "J" (Journal?)
Справочник => сокращение "S" (??????) |
|
11-05-2006 03:47сообщение от автора материала ...при делении предметной области следует манипулировать размещением объектов по схемам.
Imho, это не всегда это является лучшим решением. См. статью
"Данные: разделять или не разделять"
Замечательная статья, которая как раз и говорит о преимуществах правильного использования схем, в трех вариантах ;-)
А префиксы, еще раз говорю - пожалуйста, дополняйте какие хотите. Ведь смыслу статьи это не противоречит.
Можно ткнуть пальцем место в статье, где описываются конструктивные отличия каталога и справочника?
* S - Справочник. [...] Могут требовать инкрементального поиска, времязависимости, древовидных показов и чего угодно.
Реализация древовидности и времязависимости предполагает добавление служебных полей (а иногда и дополнительных таблиц, обсуждение деревьев было недавно), не говоря уже об ином интерфейсе пользователя.
Хотя Вы правы в том, что на границе этих понятий есть некоторая неформальная область. Ну на то мы и проектировщики, а не роботы - решать нам ;-))
|
|
11-05-2006 02:481. По поводу префиксов и выбора схемы для объектов.
Что-то мне кажется, что вы клоните к тому, что префиксы предметной области не нужны,а при делении предметной области следует манипулировать размещением объектов по схемам.
Imho, это не всегда это является лучшим решением. См. статью
"Данные: разделять или не разделять"
http://www.interface.ru/oracle/0003.htm
Продолжаю считать префиксы предметной области нормальным проектировочным решением, которое следует учитывать при разработке соглашений об именовании :)
2.
И по поводу превращения каталога в справочник <...> Они ведь отличаются
не только префиксом и кол-вом записей, но и принципами организации
Можно ткнуть пальцем место в статье, где описываются конструктивные отличия каталога и справочника? Может быть, вам это интутивно понятно. А мне - нет.
3.
>> Не описаны соглашения по использованию подчерков (_) в именовании объектов
> А еще не из статьи не понятно как наименовать специфические для каждой отдельной СУБД вещи
Соглашение по использованию подчерков - не специфичная для какой-то СУБД вещь |
|
11-05-2006 02:07сообщение от автора материала ...это продолжение. Начало в предыдущем ответе...
Теперь по некоторым замечаниям:
а вот если вы смотрите select на два листа, еще и написаный не вами [...а югославами]
Думаю, прежде чем смотреть такой SELECT, нужно все же положить перед собой соответствующий кусок ErWin-диаграммы (если нет - сделать самому Reverse Engeneering-ом), или хотя бы распечатать скрипты CREATE TABLE и выделить маркером PK и FK. По поводу наследованных систем от югославов - дело житейское. Видел я базы данных и с чешскими и с итальянскими именами - составляешь себе словарик на пару листов, и ничего...
Следующее. Для разделения предметной области (а гораздо важнее - для разделения логических кусков БД между разработчиками, а затем и между подсистемами) обычно используют схемы. Если какие-то таблицы используются несколькими предметными областями - для них создают отдельные, общие схемы (более глобальные по смыслу), аналогично принципам использования процедур в Паскалевских модулях, или (и) глобальные синонимы. Можно придумать и специальные префиксы для некоторых совсем уж общих предметных областей, но я же сказал, что "..список может быть расширен" ;-))
И по поводу превращения каталога в справочник. Это куда более тревожное замечание, чем кажется. Они ведь отличаются не только префиксом и кол-вом записей, но и принципами организации. И если у вас в середине проектирования крохотный плоский список-классификатор становится большим древовидным времязависимым справочником, то при чем тут система наименования? Недосмотр проектирования, придется что-то переделывать. Переименование - самая легкая часть ;-))
А что мало конкретных рекомендаций - уже неоднократно говорили, что собственно в правилах наименования никаких преимуществ нет. Важно, чтобы эти правила были. Поэтому конкретизировать до мелочей смысла я не вижу, и цели такой не ставил.
Еще раз спасибо за проявленное внимание. Как говорил Жванецкий, хуже всего для артиста - уходить из зала в мертвой тишине.
|
|
11-05-2006 02:06сообщение от автора материала Благодарю всех за проявленное внимание. Попытаюсь ответить, сначала по общим моментам, затем на отдельные замечания.
Прежде всего, почему-то большинство собеседников кинулись в технические детали, и прошли мимо Задачи Номер Один: "Единство именования программных единиц во всем проекте" (третий абзац статьи). Если кто-то считает это ненужным, то дальнейшие подробности об англоязычности и сокращенности теряют смысл. Если же нужным, то давайте еще раз пройдемся по рассуждениям:
1. Создание базы данных - не самоцель. Мы строим к ней различные запросы, пишем триггеры, процедуры, как на сервере, так и на клиенте, строим формы, создаем отчеты. При этом мы создаем классы, свойства, объекты, переменные, прямо или косвенно связанные с содержимым БД, то есть кодируем обвязку.
2. Идея заключаеся в том, чтобы поддерживать единство именования всех этих... вещей во всех слоях проекта. Другими словами, если у "улицы" имеется атрибут "название улицы", то хотелось бы, чтобы имели одинаковое название:
2.1 - поле БД "название улицы"
2.2 - поле результата *любого* SQL-запроса, содержащего "название улицы"
2.3 - соответствующее поле всех клиентских наборов данных, как для ссылок из DBAware-компонентов, так и для программного обращения FieldByName
2.4 - локальные переменные, свойства классов, используемые в процедурах (именно здесь множественное число начнет резать глаза)
2.5 - начинка отчетов (независимо от технологии приготовления).
Цель всего этого - облегчить понимание и сопровождение задачи, как во временнОм аспекте, так и в коллективной разработке.
3. Какое же должен быть принцип наименования полей БД в этом случае? Приходим к неизбежности включения имени сущности в имя поля. Иначе нам придется делать это через SELECT AS..., бессистемно, каждый раз размышляя, как бы назвать gas_distributing_station.name, если в запросе, оказывается, уже был city.name или gas_distributing_station_boss.name ;-)
4. А отсюда следует, что имена сущностей должны быть покороче. Не скрою, разумеется, у меня на практике они длиннее 2-4 символов, некоторые бывают и по 16. Но если бы я всеми силами не стремился их сокращать, было бы куда неудобнее таскаться с длинными названиями всего и вся. Кстати, оппонент игнорировал мой вопрос относительно ЖЭУ ;-)
Разумеется, если от всей этой "Задачи Номер Один" отказаться, то можно придумать куда более изящные и экономные правила именования объектов базы данных. Но тогда для именования всего остального придется выдумывать свои правила.
По поводу языка. У меня около 80% названий - чисто английские слова и части слов (в том смысле, что глядя на имя атрибута любой догадается что это такое), а оставшиеся 20% - сокращения вроде k13, который символизирует "коэффициент надбавки стоимости за отопление сверхплощади" ("сверхплощадь" - у нее свое развернутое определение ;-), и которые расшифровываются, конечно, только через комментарии и словарик. Вот среди этих 20% белиберды, чего греха таить, встречаются русские сокращения - 'GeuID', 'GeuName', '...cgv'. Ешьте меня, мухи с комарами! Я не знаю, как сделать удобнее ;-)
Если бы я создавал проект на иноязычную аудиторию, разумеется, я использовал бы 100% английских слов, но лишь после того, как ознакомился бы с английским словарем профессиональных терминов и сокращений предметной области.
..продолжение в следующем ответе... |
|
11-05-2006 00:42В именовании таблиц предусмотрен служебный префикс, но не
предусмотрено префикса предметной области - необходимая вещь,
когда в 1 схеме/базе данных соседствует несколько связанных предметных областей.
Предметные области имеют свойство пересекаться :) И как именовать будем в таком случае?
Не описаны соглашения по использованию подчеркам (_) в именовании объектов
Угу :) А еще не описаны соглашения по наименованию views, триггеров, генераторов/сиквенсов. А еще не из статьи не понятно как наименовать специфические для каждой отдельной СУБД вещи, типа dblink-ов.
|
|
10-05-2006 23:20Статья в целом понравилась, хорошее начало для дальнейшей разработки темы.
Некоторые неустаивающие моменты:
1.
В именовании таблиц предусмотрен служебный префикс, но не
предусмотрено префикса предметной области - необходимая вещь,
когда в 1 схеме/базе данных соседствует несколько связанных предметных областей.
2.
Не описаны соглашения по использованию подчеркам (_) в именовании объектов.
Суть дилеммы на примере:
CУБД Oracle.
Есть таблица MA_CASH_FLOW_ARCHIVE (Архив движения по кассе для управленческого учета
(префикс MA_=management accounting=управленческий учет))
Без подчерков в системном словаре (и соответственно, во всех инструментах для работы с БД)
это имя будет выглядеть как MACASHFLOWARCHIVE. Абсолютно нечитабельно и неудобно.
3.
Размытая граница между понятием каталога и справочника. При детализации
модели каталоги будут постепенно перерастать в справочники.
Что тогда - переименовывать объекты БД?
- Два - это куча?
- Нет, не куча.
- А три?
- Три, пожалуй, куча. (из какого-то мультфильма)
4.
В статье много размышлений и рекомендаций, но мало четких формальных правил.
Что не согласуется с эпиграфом статьи :)
5.
Хотелось бы видеть список ссылок по теме. Подкидываю несколько (всё на английском,
на русском серьезных материалов не нашел. Если есть аналоги, выкладывайте,
с удовольствием почитаю.
Oracle ENTERPRISE STANDARDS Naming Conventions, Diagramming Guidelines
and PL/SQL Standards.
By Tom Morgan, Software Engineer, BlueFinger Limited
http://www.quest-pipelines.com/pipelines/dba/archives/Oracle_Standards.zip
ORACLE-BASE - Oracle Naming Conventions
http://www.oracle-base.com/articles/misc/NamingConventions.php
ISO 19115 Oracle Implementation Naming Conventions
http://www.bgs.ac.uk/cgi_web/tech_collaboration/metadata/docs/namingconventions.pdf
Дискуссия на AskTom
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:6729304326802
Database object naming conventions (For SQL Server databases, tables,
views, triggers, indexes, <...>) Narayana Vyas Kondreddi's home page
http://vyaskn.tripod.com/object_naming.htm |
|
10-05-2006 12:412 Сабир Сафаров
Имя должно быть уникальным в пределах базы данных.
Читаем, еще раз, внимательно... автор говорит о именах вообще, как о идентификаторах, то что они должны быть уникальны. Имена бывают не только у таблиц... у полей тоже. А разных таблиц у которых поля называются одинаково (id, name) думаю у всех достаточно. Почему я сказал, что это не возможно, поясню: дело в том что БД использует символьные идентификаторы не только для таблиц и полей и, обычно содержит не только таблицы пользователя... еще и словари данных самой БД... и пакеты стандартных процедур поставляемые вместе с БД...
Любая нормальная нормальная СУБД напишет "Object named XXXX already exist", если вы попытаетесь добавить таблицу или вьюшку или сиквенс или триггер с таким же именем, но я не видел ни одной СУБД, у которой было бы ограничение на имена идентификаторов для всех объектов БД, например имена процедур в пакетах в Oracle.
2 Fisher
Газораспределительная станция - gas_distributing_station. Отличное название.
Дата включения ЦГВ - date_from, а если нет даты выключения, то turnon_date, полагаю ЦГВ относится к таблице :) или вы ко всем полям CGV у себя привинтили?
А как вы называете у себя в базе НДС
VAT, исключительно потому, что так более понятно, чем Value Added Tax
Писать нужно обязательно пользуясь английским словарем, так будет понятнее всем. Пример из жизни: Представте себе промышленную систему, которая непрерывно работает, которую нельзя остановить и поэкспериментировать с ней на предмет определения того, что там за данные и в каком поле что находится. А нельзя потому, что систему делали югославы и поля в Оракле названы по-югославски. И вот, открываю я таблицу
moia_ne_govorit_po_angl, а там 20 полей названых fityuw, huoptyn, derui, terio_tyg и тому подобные "говорящие" имена полей и все поля чиловые... в каждом какой-то параметр действующей установки :) Видимо, югославы не думали, что кто-нибудь кроме них туда полезт. Однако, все может случиться... :)
Во-первых, первое ;-)
Во-вторых, подчеркнутое (если это документация) или то что в конструкции PRIMARY KEY (если это скрипт) - куда Вы, кстати, допустим, смотрите?
В третьих, если бы Вы не откусили названия таблицы sStreet, то стало бы очевидно, что StreetID.
Это хорошо, когда в документации или в скрипте, а вот если вы смотрите select на два листа, еще и написаный не вами, то увидев что-нибудь типа:
st.StreetID = stt.StreetID
Придеться соображать, с какой стороны тут primary key, а с какой foreign. Все таки я настаиваю, что "ID" - проще и понятнее. О другой не очевидности я уже написал:
(streetid,
sityid,
strtypeid)
select streetid, sityid, strtypeid from smth
и
select sityid, streetid, strtypeid
Вернут первым разные поля :)
И позвольте вопрос с моей стороны. Имена сущностей Вы предлагаете растить до 32 знаков. Мысль о том, что в название полей таблиц включаются имена сущностей, возражений у Вас не вызвала.
Вызвала. Это просто кошмар... и остальное тоже... Просто, я не могу физически откомментировать каждое слово в вашей статье, у меня нет для этого времени. В целом очень хорошая идея - стандартизация процесса наименования объектов БД, но под вашим соусом, выглядит крайне неудачно. |
|
10-05-2006 12:36Хочу сказать большое спасибо автору статьи что он не просто ответил на мой вопрос но и целую статью "забахал", за это ему (FISHER) отдам свой голос. А статья весьма удачная и со многим я согласен и самое главное есть опыт опытных коллег на основании которого я и буду разрабатывать свои стандарты :)
|
|
10-05-2006 11:41Почти со всем согласен. Попробую обозначить те моменты, с которыми не совсем согласен или совсем не согласен (экий я каламбур завернул ;-)
Насчет длины. 2-4 символа -- это все же маловато. Все значимые слова таких размеров наперечет. Если пытаться втиснуться в такие рамки, то речь уже пойдет о сокращениях, а это не есть гут. Для меня идеал -- старые добрые ДОСовские 8 символов.
Насчет единственного и множественного числа. Никому не хочу ничего навязывать. Это дело вкуса. Мне предпочтительнее множественное число (хотя на практике случается по всякому). Почему? Ну, во-первых, аргумент, приведенный в статье насчет WHERE, не работает:
WHERE streets.cityid -- можно прочитать так: "Где одна из улиц, с ключом равным...". Как видно, слово улицы здесь именно во множественном числе, а в единственном -- cityid. По правилам русского языка (и по соображениям здравого смысла) род и число в сложных конструкциях определяется последним словом. Восемнадцать тысяч триста восемьдесят один рубль (но не рублей). В плане соотношения единственного и множественного чисел мне больше бьет по глазам VCL.
TWinControl.Controls -- вроде бы правильно. Однако
MyControl:=Form1.Controls[i] -- уже как-то бьет по глазам. И ничего, привыкли.
Насчет имен полей. Не понимаю я этих аргументов, почему надо делать префикс из имени таблицы. Мне наоборот удобнее, когда в разных (но схожих) сущностях используются одинаковые названия полей. И не пойму я, почему CityName лучше, чем City.Name. А про то, что названия полей в рекордсете будут дурные, так они и так будут дурные. Если это важно для отображения, то вообще нужно давать псевдонимы на русском языке (хотя этого делать не стоит). Если же предполагается использование FieldByName (что происходит далеко не всегда), то можно дать подходящий псевдоним. Это не трудно.
Ссылки. А вот тут я использую в качетсве префикса имя таблицы. По моему выражение City.CountryID = Country.ID понятно без перевода. А одинаковые названия для связанных полей требуются только в Аксессе, если лениво связи прописывать руками ;-)
По поводу первичных ключей. Поддерживаю и Алексея Михайличенко, и Анатолия Тенцера. Одно поле на искусственный первичный ключ. Не надо смешивать сущности. Первичный ключ служит для организации связей в БД. Так пусть он только этим и занимается. А сложный запрос с таблицей, в которой в качестве первичного ключа используется три поля, я, наверное, и не сразу построю. Причем читаемость будет никакой, а вероятность возникновения ошибок резко возрастет. Кстати, во времена Клипперов для идентификации использовали RecNo. И никто не бурчал, что нужно заводить специальное поле для идентификации записи, которое бы имело смысл. И ничего... работали.
Несколько слов по поводу языков. Я знаю и люблю русский язык. Но в программировании отдаю предпочтение английскому. И тому есть, как минимум, две причины. Во-первых, английский язык более емкий, соответственно, можно достигнуть той же информационной насыщенности меньшим количеством символов. А более короткие фразы читаются легче. Во-вторых, английский язык мне не родной, и за его фразами не стоит столько скрытых смыслов, которые отвлекают. Вспомните замечательный шедевр школьной информатики -- Бейсик, переведенный на русский. Оператор "иди на" вызывал неизменный хохот у всех учеников. В общем и названия таблиц с названиями полей лучше делать английскими буквами. Пусть нам тот же Аксесс предлагает самые широкие возможности по использованию русского языка, не надо попадать в эту ловушку. С этими названиями потом работать. Пусть русские названия используют домохозяйки. Они все равно ни одного запроса ни разу не написали. Они их в билдере строят.
Мои типовые названия для полей:
ID -- искусственный первичный ключ (автоинкремент)
Name -- имя, название (текст 20-40). Если требуется полное имя, то Name остается за системным именем, а полное задается как FullName
Code (реже Key) -- естественный первичный ключ в тех редких ситуациях, когда это необходимо; в остальных случаях -- какой-то содержательный код или шифр
Note (реже Info) -- мемо поле, добавляемое на автомате практически к любой таблице-сущности, чтобы занести туда все то, подо что я забыл отвести поле.
В общем, тема очень объемная и говорить можно долго. Прям хоть садись и пиши аналогичную статью ;-)
P.S. Все сказанное ИМХО (для тех, кто этого еще не понял).
P.P.S. Несколько слов уважаемому ZeroDivide...
Сударь! Видимо, когда Бог раздавал людям вежливость, Вы стояли в очереди за самоуверенностью ;-) Надо быть все же повежливее. Любые самые гениальные Ваши идеи будут отвергнуты, если подавать их подобным образом. |
|
10-05-2006 09:37сообщение от автора материала Добавлю: из словаря английского языка. Аббревиатурой ни в коем случае нельзя. Сокращать тоже не нельзя (впрочем, зависит от длинны имени в конкретной СУБД)
О сокращениях. Предположим, техническое ограничение на длину имен отсутствует. Предложите, пожалуйста, простое и понятное имя из словаря английского языка для сущности "ЖЭУ" (Жилищно-эксплуатационное управление).
А еще для "ГРС" (Газораспределительная станция) и "ГРП" (Газораспределительный пункт). Как бы вы предложили назвать поля "КТУ" (коэффициент трудового участия), "Дата включения ЦГВ" (Централизованного горячего водоснабжения)? А как вы называете у себя в базе НДС?
Даже если во всех этих случаях Вам без сокращений удастся уложиться в 32 символа, вряд ли читаемость SQL-запросов от этого выиграет.
А что касается исключительно английского языка, то мне кажется, что стопроцентное следование англоязычным терминам имеет смысл только тогда, когда в команде есть англоязычные партнеры. А иначе это дело вкуса и здравого смысла.
# Имя должно быть уникальным в пределах базы данных.
Это вообще не возможно.
Вам удалось всех заинтриговать. Надеемся на развитие этой мысли.
Далее....
Вот, допустим, я вижу таблицу
(streetid,
sityid,
strtypeid)
... ужасные названия полей :( Где по вашему, какое-то из полей является первичным ключем. Какое?
Во-первых, первое ;-)
Во-вторых, подчеркнутое (если это документация) или то что в конструкции PRIMARY KEY (если это скрипт) - куда Вы, кстати, допустим, смотрите?
В третьих, если бы Вы не откусили названия таблицы sStreet, то стало бы очевидно, что StreetID.
И позвольте вопрос с моей стороны. Имена сущностей Вы предлагаете растить до 32 знаков. Мысль о том, что в название полей таблиц включаются имена сущностей, возражений у Вас не вызвала. Если предположить по аналогии, что в смысловой части названия поля Вы тоже допускаете 32 символа, то выходит, что общая длина названия поля может достигать 64 символа? Удобно ли?
|
|
10-05-2006 07:53to ZeroDivide:
# Имя должно быть уникальным в пределах базы данных.
Это вообще не возможно.
Приехали... Вообще-то с этого начинаются учебники по реляционным базам - "таблица должна иметь в пределах БД уникальное имя" |
|
10-05-2006 07:33по первому же отклику понял, что автор затронул очень интересную тему :o)
В прениях находиться лучшее решение. |
|
10-05-2006 07:31А мне удобней в однотипных таблицах использовать однотипные имена. Наверное дело привычки. И лично мне кажется, что читать базу легко :o)
Почему удобней? Пример: Допустим у меня 10 таблиц-списков всего с двумя полями - id,name.
1) Delphi:
Настраиваю запрос на одну из таблиц и под него грид (не ругайте, просто мне нравиться грид) на эти два поля. Если нужно использовать эту форму для редактирования другой таблицы, просто меняю текст запроса - всего одну строчку в коде.
2) C#:
Здесь грид настраивается посложней, но принцип тот же: после изменения источника данных просто меняется одно свойство MappingName - и грид настроен
this.dataGridTableStyle1.MappingName = "Имя_Таблицы";
Конечно, методика кривовата, зато время экономиться. |
|
10-05-2006 07:10Ужасная статья, удалите пожалуйста ее, дабы она не смущала тех, кто не очень хорошо разбирается в проектировании БД.
Я руками и ногами за стандартизацию идентификаторов объектов БД, но не в таком виде, какой предлагает автор.
# Имя должно быть существительным (полным, сокращенным либо аббревиатурой) в единственном числе.
Добавлю: из словаря английского языка. Аббревиатурой ни в коем случае нельзя. Сокращать тоже не нельзя (впрочем, зависит от длинны имени в конкретной СУБД)
# Имя должно быть как можно короче. Оптимально - 2-4 буквы, максимум до 10.
Имя должно быть как можно понятнее и как можно точнее отражать суть содержимого. Максимум я бы ограничил в 32 символа.
# Имя должно быть уникальным в пределах базы данных.
Это вообще не возможно.
# Имя должно быть мнемонически понятным проектантам без заглядывания в словарь (но словарь такой хорошо бы составить).
Чего?
Далее....
Вот, допустим, я вижу таблицу
(streetid,
sityid,
strtypeid)
... ужасные названия полей :( Где по вашему, какое-то из полей является первичным ключем. Какое? А фиг знает какое! Вот если вы я видел
(id,
sity_id,
street_type_id)
Я бы точно вам сказал, что id - это primary key данной таблицы, sity_id - foreign key на id в таблице sity... ну и street_type_id, соответственно.
В этом месте обычно вспоминают о возможности SELECT cstrtype.name AS strtypename
Почему вспоминают, ни кто и не забывает :)
Это собственно обозначения содержимого полей
# code - пользовательский идентификатор, уникальный ключ. Например, табельный номер сотрудника. Как правило, неизменный; но при необходимости его можно менять (когда у отдела кадров сносит крышу), причем без каскадных обновлений БД.
# name - имя чего-либо (скорее идентификатор, или нечто каноническое)
# label - название (обычно человеческое удобное название)
# notes - поле типа TEXT, для примечаний
# num - номер чего-либо (может быть числовой либо текстовый, например Письмо N "1234/56-789")
:) |
|
|
|
