Правила именования таблиц и столбцов БД

Господа, товарищи, граждане, помогите!
В части правил именования таблиц и столбцов в интернете царит жуткий разнобой.
Нет ли таких правил, которые стали хотя бы относительно устоявшимся стандартом для всех, или для вашей компании, или для вас лично? Будьте так добры, дайте ссылку на них.
P.S. Не хочется без крайней нужды изобретать велосипед. Точнее - попытался изобрести и уже вижу, что колеса не вполне круглые

0

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

Не ожидал такого)
Вот тут полный список зарезервированных слов по (стандарту).

Список зарезервированных ключевых слов ANSI SQL (92, 99 and 2003), MySQL версий с 3 по 5.x, PostgreSQL 8.1, MS SQL Server 2000, MS ODBC и Oracle 10.2.

Не понятно почему некоторые из них выделены жирным.
NAME - обычный шрифт
NAMES - жирным

Добавлено через 3 минуты

Сообщение от Gluck99 Соответственно, всячески избегайте первого, а второе придёт со временем.

Спасибо, это я как раз сегодня уже осознал.

0

Сообщение от titan4ik Имена таблиц и представлений должны подчиняться стандартам и выражаться существительными множественного числа

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

Сообщение от titan4ik А у меня после ознакомления с большим числом источников сложилось впечатление, что в случае возможности дать обобщенное наименование таблицы в единственном числе - так и следует поступать, то бишь - "персонал".

Это "конкурирующая фирма" академических теоретиков. Я из лагеря "тактических практиков". Академические теоретики пишут книжки с правильными и корректными подходами, которые, правда, работают в основном только в лабораторных условиях и в учебных задачах. Практикующие разработчики имеют дело с реальной жизнью, в которой заказчик может изменить ТЗ на 180 градусов, не заплатить денег и вообще может случиться бог знает что ещё, от коронавируса до санкций. В этом случае правильнее использовать те подходы, которые позволяют гибче решать возникающие проблемы, не связанные с теорией БД, но оказывающие на неё корректирующее давление.

1

Сообщение от Gluck99 Это "конкурирующая фирма" академических теоретиков. Я из лагеря "тактических практиков".

ОК.

Добавлено через 5 минут
Gluck99, попробую придерживаться, для начала, ваших правил. Или около того (?).
Если у Вас будет возможность, может быть дадите более детальный их вариант? Это было бы интересно всем - было бы меньше подобных тем и подобного битья об стену лбом.

Добавлено через 7 минут

Сообщение от titan4ik Или около того (?).

Всё-таки суффиксы для полей, как рекомендует ДжоСелко Джо_Селко Джо Селко удобно добавлять в каких-то случаях. Он это делает через нижнее подчеркивание. Я, честно говоря, и в коде (c#) иногда так делаю.

0

Сообщение от titan4ik Он это делает через нижнее подчеркивание.

Я просто избегаю нижнее подчёркивание. Не имею ничего против него в принципе, но я стараюсь минимизировать его использование. Мои субъективные аргументы против:
а) чисто технически неудобно набирать - надо жать SHIFT, скорость работы уменьшается;
б) в случае смешанного применения нижнего подчёркивания надо помнить, где ты его ставишь (в каких случаях), а где нет. Это требует разработки дополнительных правил. В моей парадигме подчёркивание только для имён таблиц - там каждое слово отделяется подчёркиванием и сразу ясно, как это выглядит. Для имён полей - горбатая нотация, и тут подчёркиванию практически нет места. Хотя я использую его и тут (редко) в основном для создания соответствия нотации на клиенте и в БД, иногда такое бывает полезно. Например, у нас есть какие-то наборы атрибутов на клиенте вида GHP_NAME_SCREEN_TOOL (выдумал только что), соответственно, поле имеет смысл назвать таким же образом. Обычно такое бывает в части обработки и хранения технических данных. Что касается бизнес-логики и прочего - там подчёркивание ни к чему;
в) теряется эстетика, а она является обратной стороной читабельности.

Сообщение от titan4ik Всё-таки суффиксы для полей, как рекомендует ДжоСелко Джо_Селко Джо Селко удобно добавлять в каких-то случаях.

У меня такое проходит как исключение из правила.

1

Понятно, спасибо!

Добавлено через 16 минут
Забавно!
Джо Селко не уступает в харизматичности формулировок самому Дейту:

Некорректные имена элементов данных имеют своим источником невежество и объектно-ориентированное программирование (ООП). В частности, объектно-ориентированные программисты обязательно добавляют суффикс «_id» к любому первичному ключу любой таблицы, не понимая, что SQL — сильно типизированный язык, и в нем сущности в ходе выполнения программы своего типа не меняют.

0

Сообщение от Gluck99 Я просто избегаю нижнее подчёркивание

я наоборот - во всех именах применяю подчеркивание, что улучшает их читабельность, упрощает экспорт таблиц/запросов в ексель( я просто выделяю первую строку и заменяю подчеркивание на пробел) , аналогично и для заполнения шаблонов ворд

переключение регистра ничуть не быстрее ввода символа пдчеркивания

1

Сообщение от shanemac51 я наоборот

Спасибо!

Добавлено через 1 минуту
но логику использовать горбатую нотацию можно понять - так рекомендуют в c#, например, и для полного соответствия полей таблицы и переменных в c# это как бы логично. Но не догма!

0

Попался очередной опус на тему правил наименования.
Опять что-то своё. Опять абсолютно противоречит во многом другим опусам. До смешного.
Вывод - делать так, как это удобно тебе лично. Понять бы только ещё как мне удобно
Как правило, понимаешь это слишком поздно) Когда удобно, это как правило не замечаешь, а вот когда неудобно - оно сразу вылазит)
Мда. Беда
С такого рода бедами постоянно сталкиваешься "в программировании". Это из-за того, что практика бежит впереди теории и либо теория не поспевает, либо теория не поспевает никогда - практическая область успевает настолько быстро преобразовываться. что теория постоянно где-то сзади, как кандалы непонятного предназначения. Мне кажется, что в СУБД это особенно очевидно.

0

слишком длинные наименования загромождают как код программы, так и текст запроса. и, соответственно , усложняют жизнь при отладке. выбирая между ПроцентНалогаНаДобавдленнуюСтоимость и НДС я бы 100% выберу второе ) слишком короткие и не информативные наименование еще хуже. из этого и исходи

зы как-то работал со старым dbf-ником с наименованиями полей f1, f2,f3 и т.д. мрак ))

1

Сообщение от Аватар выбирая между ПроцентНалогаНаДобавдленнуюСто имость и НДС я бы 100% выберу второе )

Лучше будет, наверное - СтавкаНДС или НДС_Ставка - если я правильно понял. А если сам налог, то НДС это отлично, как мне кажется.

Добавлено через 27 минут

Сообщение от Gluck99 В-третьих, по поводу "полной записи". Вы, коллега, ещё пока не имеете большого опыта, поэтому не знаете, что к таблицам в более или менее сложных запросах обращаются по псевдонимам. В мелких учебных запросах так обычно не делают, но сколько-нибудь продвинутые разработчики используют псевдонимы в большинстве запросов. Соответственно, ваш пример cities.CityName превращается в c.CityName, что однозначно указывает на содержимое поля и не может вызвать разногласий, даже если вы забыли, что "с" - это "cities".

Gluck99, если Вам эта тягомотина надоела, то можете не участвовать. Но от этой вашей фразы у меня когнитивный диссонанс. Смысл фразы мне понятен. Но тут Вы сами создаёте проблему, а потом объясняете как Вы её решили изначально.
Не проще ли было сделать информативный псевдоним для таблицы cities? Например city. И тогда было бы city.Name - всё понятно, название города (то, что Name это зарезервированное слово забудем на минутку, странно, что такое слово исключили из употребления).
Хотя тут псевдоним не сильно короче - ведь city не сильно короче cities - но это в данном примере так, а если название таблицы громодкое, то псевдоним из одного слова может быть уместен. Но и тут всё-таки короче и меньше шансов сделать орф ошибку)))
Псевдоним делается для сокращения записи. А тут в вашем примере получается, что название таблицы сокращается, а название столбца увеличивается. В итоге (конкретно в вашем примере) никакого сокращения.
Я уж не говорю о том, что если небольшой запрос, то и псевдоним "с" не даст забыть, что это город.
В общем, мне пока не очевидно, что нужно почти ко всем названиям столбцов лепить название сущности (согласно имени таблицы).

Добавлено через 4 минуты
Дело в том, что я начал уже было этот процесс переименования. И теперь вид структуры таблиц стал меня ужасать - пестрит везде эта сущность)))
Не менее ужасает, что Name нельзя использовать для имени столбца.

Добавлено через 23 минуты
До кучи - о читаемости текста в верблюжьей нотации и с нижним подчеркиванием (но число испытуемых в исследовании не велико)

An Eye Tracking Study on camelCase and under_score Identifier Styles

Результаты данного исследования за подчеркивание. Хотя в коде (в c#), на мой взгляд, постоянное подчеркивание выглядит ещё более ужасно, чем верблюжья, а иногда, для суффиксов каких то особых - вполне уместно.

0

Сообщение от titan4ik мне пока не очевидно, что нужно почти ко всем названиям столбцов лепить название сущности (согласно имени таблицы).

Вы несколько запутались в трёх соснах, а теперь говорите, что неочевидно. Название сущности "лепить" в дочерних таблицах. В родительской (там где примари кей) остаётся ID. Так как обращение идёт через псевдонимы в 99% случаев, у вас получится x.ID = y.FieldID, т.е. нотация ни слева, ни с права не избыточна и позволяет понять, к чему относится то или иное поле.
Сокращать cities до city никакого смысла нет от слова совсем. Тот же Джо Селко делает псевдоним из одной буквы и цифры. К цифре у меня вопрос, кстати. У него в примерах кода псевдоним таблицы имеет наименование с1 и т.п., и по идее, где-то должен быть и с2, и, возможно, с3. Но их нет и быть не может. Я против цифр в псевдонимах, они только создают лишнюю неопределенность. Как исключение - да. А так псевдоним должен быть не длиннее трёх символов: x, xy, xyz. Для основных таблиц запроса один знак, для подзапросов и джойнов - 2 или 3 знака.

1

Сообщение от Gluck99 Вы несколько запутались в трёх соснах

Не один я, к сожалению
Почитываю разные источники и только диву даюсь.

Добавлено через 1 час 54 минуты
Gluck99,
спасибо! Я уже близок к разработке черновика собственного "корпоративного" стандарта)
Пара уточняющих вопросов по вашему:
1. В названиях таблиц Вы используете только маленькие буквы и разделяете слова нижним подчеркиванием? А если в название будет входить аббревиатура?
2. Все названия полей (столбцов) начинаете с большой буквы?
3. Используете ли в названиях таблиц и полей кириллицу? Никогда, или иногда, или везде где хочется?

0

Сообщение от titan4ik Почитываю разные источники и только диву даюсь.

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

Сообщение от titan4ik 1. В названиях таблиц Вы используете только маленькие буквы и разделяете слова нижним подчеркиванием? А если в название будет входить аббревиатура? 2. Все названия полей (столбцов) начинаете с большой буквы? 3. Используете ли в названиях таблиц и полей кириллицу? Никогда, или иногда, или везде где хочется?

1. Маленькие, потому что название таблицы не так важно, как название поля. Наименование таблицы фактически используется один раз в коде, далее его псевдоним. Т.е. акцент всегда на поле, а не на таблице. Мы смотрим на наименование поля, и если хотим понять откуда оно - смотрим на псевдоним слева.
По названиям таблиц есть один важный, но многим неочевидный нюанс. Если СУБД установлен на Windows, то имена будут нечувствительны к регистру. А если на Linux - возможны варианты. Так, на Linux-MySQL запрос вида
выдаст ошибку "таблица не найдена", если название таблицы на самом деле My_Table. При этом наименования полей останутся нечувствительны к регистру в обеих ОС.
Поэтому удобнее держать имена таблиц всегда в нижнем регистре - на любой ОС и на любом клиентском коде вы будете избегать глупых ошибок.
2. Да. Но возможны исключения в виде префиксов: lstNumberA, frmCaptionByte и т.п., когда надо выделить множество однородных полей в некую именованную группу.
3. Кириллицу (и тем более транслит ) не использую нигде и никогда, даже в виде исключений. Равно как и специальные символы, пробелы и т.п. Несмотря на возможности экранирования, ничего хорошего это не сулит, плюс ухудшает эстетику, а как я уже говорил, это обратная сторона читабельности. Официальный язык наименований - английский. Единственное место, где я использую кириллицу - это заметки-комментарии к полям, таблицам, триггерам и т.д.
Вообще, разрабатывая стандарты для нейминга, надо держать в уме ещё и тот факт, что с вашей БД может работать не только ваше клиентское приложение, но и какое-нибудь другое (да, такое бывает). Причём написанное на незнакомом вам языке программирования и функционирующее на какой-нибудь не очень популярной ОС, и вообще с интерфейсом на арабском (внезапно!) языке. Задача вашей системы нейминга не усложнить работу таким приложениям (специальными символами, национальной кириллической кодировкой и т.п.), а облегчить. Латиница + английский язык = универсальность, независимость и некая гарантия работоспособности, несмотря на широкое распространение юникода.

1

Сообщение от titan4ik Не менее ужасает, что Name нельзя использовать для имени столбца.

использую namep -fнаименование полное, names - сокращенное, если оно есть, а бывает часто, особенно в справочниках, а еще и суперсокращенное, почти что аббревиатура - namesk )

1

Сообщение от Аватар использую namep - наименование полное, names - сокращенное, если оно есть, а бывает часто, особенно в справочниках, а еще и суперсокращенное, почти что аббревиатура - namesk )

Спасибо, понятно. Но это такой суперличный стандарт. Зато кратко. Буду иметь ввиду, что и так можно. Подход оправдан тем. что поле "Name..." приходится часто использовать. И такая краткость не помешает читабельности - трудно забыть её смысл.

Сообщение от Gluck99 Это нормально.

Спасибо за ответы. Понял. Теперь у меня есть всё для выработки первого приближения своего стандарта.)
P.S.
У меня тут по ходу дела надо будет чужие данные обрабатывать периодически. Они в виде таблице в файле CSV. И там наименование полей на кириллице. Полей очень много. И я всё-таки решил на базе данных файла делать таблицу с теми полями, какие определены в этом файле - на кириллице. Поставлю вместо пробелов нижнее подчеркивание. Делать новый нейминг довольно муторно. Ввиду большого количества полей и мудрености терминологии. Но это будет таблица из разряда details. А самые реально нужные поля из них (штук 15-20) переименую в латиницу и на их базе сделаю основную таблицу. У этих таблиц будет одно число записей и соответствие будет по ID (один к одному). Как-то так.

Добавлено через 7 минут
Аватар, Вы поля с маленькой буквы именуете?
Я пока склоняюсь к тому, чтобы поля с большой именовать.
Добавлено через 5 минут
А то просится так - NameP, NameS, NameSk или NameSK.
А если наименование на русском и на английском, то английские пометить NameEnP, NameEnS...
Мда, чисто визуально немного напрягает.
Как ни странно, namep, names, namesk смотрится лучше. То, что это имя и так сразу видно, а чтобы разобраться в деталях - краткое или нет можно и присмотреться. Это к слову о подаче информации разного уровня значимости.

Добавлено через 5 минут
Ещё вариант использовать суффиксы после подчеркивания - name_p, name_s, name_sk. Но так эта деталь (краткое или полное) сразу визуально вылезает на первый план, хотя она далеко не всегда значима.

0

Сообщение от titan4ik Как ни странно, namep, names, namesk смотрится лучше.

Не уверен, что лучше. В этом случае вам очень часто придётся выбирать между хорошим английским словом для наименования поля и тем, во что оно может трансформироваться путём добавления постфиксов. Даже вот это банальное name превращается в names - и уже непонятно, это множественное число или просто постфикс? Допустим, вы знаете, а незнакомый с вашими стандартами человек не догадается, потому что это неочевидно, гораздо разумнее предположить, что это именно множественное число. Или, например, name -> namer -> namers. Что это - "именователь", "именователи" или name + постфикс "rs"? А если написать NameS, NameRS или Names, Namer, Namers - никаких сомнений не будет. Причём вы можете использовать оба варианта одновременно в разных таблицах (что нежелательно, но как вариант возможно).
Или возьмём другое слово - сomment. Оно, кстати, как и name зарезервированное. Как называть поле? Comment нехорошо, надо бы Comments. Но если это comments, то опять-таки что это - множественное число или comment + постфикс "s"?

И т.д., и т.п.

1

Сообщение от Gluck99 А если написать NameS, NameRS или Names, Namer, Namers - никаких сомнений не будет.

NameS - это понятно, что не мн. число. А Names почему не множественное? Или я что-то не понял.

0

Сообщение от titan4ik Вы поля с маленькой буквы именуете?

с большой, составные разделять удобно - ProdId, EdIzm и так могу, зато всем понятно )

1

Сообщение от Аватар с большой, составные разделять удобно - ProdId

ОК. А почему тогда ваш пример с names был с маленькой? Вы "всю улицу сбили с ритма")))

0

та просто лень было шифт удерживать )

0