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

@titan4ik · 01.09.2022, 13:00. **Показов** 7328. **Ответов** 55

Студворк — интернет-сервис помощи студентам

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

@titan4ik · 05.09.2022, 19:52 **[ТС]**

Сообщение от Аватар

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

Вот так человечество и погибнет

@Gluck99 · 05.09.2022, 20:01

Сообщение от Аватар

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

titan4ik, Понятно, почему я избегаю нижнее подчёркивание?

@titan4ik · 05.09.2022, 20:21 **[ТС]**

Сообщение от Gluck99

Понятно, почему я избегаю нижнее подчёркивание?

Мне уже начинает казаться, что предпочтения людей относительно наименований в SQL лежат не в ментальной, а в какой-то более глубокой ипостаси. Может вас на астрологические знаки нужно предварительно протестироваь? Или по группам крови разбить? А объяснить и обосновать самые противоположные вещи вы умеете

Я имею ввиду не только тех, кто тут отписался, но и ваще всех, кто высказался на просторах интернета за эти десятилетия существования проблемы)

Добавлено через 10 минут
Всем спасибо!
Пойду выпью винца хорошего красного и займусь своим стандартом

@Gluck99 · 05.09.2022, 21:14

Сообщение от titan4ik

предпочтения людей относительно наименований в SQL

Предпочтения людей вообще вещь сложная и подвержена интерференции самых разнообразных факторов: от генетически обусловленного поведения до культурных установок, полученных в детстве. Это называется "психология выбора".
Удивляться этому так же бессмысленно, как удивляться разным музыкальным или гастрономическим пристрастиям людей. В конце концов написание кода - это особый вид литературы. А литература подчиняется в том числе законам эстетики текста. А эстетика - это как выбор между грушей и яблоком, горьким шоколадом и молочным, красным вином или белым. Вот у вас красное на столе, а кто-то скажет - кислятина! (Я тоже склоняюсь к красному, если что; хотя от белого не отказываюсь обычно).

Сообщение от titan4ik

объяснить и обосновать самые противоположные вещи вы умеете

А нет никаких "противоположных вещей". Это называется диалектика. В одной сущности в то же самое время могут жить противоположные тенденции. Закон природы, инь и янь.

@titan4ik · 06.09.2022, 00:45 **[ТС]**

Сообщение от Gluck99

Я тоже склоняюсь к красному, если что; хотя от белого не отказываюсь обычно

Вот это разумно! Аналогично. Разве что добавил бы к красному и белому ещё и беленькую (в разумных микродозах), а также коньяк, виски и остальное - по вкусу. Не будет себя ограничивать. Выбрать адекватное ситуации и себе питие - это искусство.

Не по теме:

Поскольку я в жизни разными вещами занимался, я Вам так скажу. Есть известное высказывание. что не существует здоровых людей, есть недообследованные. И так же, если даже правила наименования являются предметом личных предпочтений программистов, а само написание кода - искусством (Вы фактически это сказали), то это может говорить только об одном - этот род деятельности недоделан технологически. Такое встречается и в других отраслях - например, конструирование некоторых узлов в машиностроении до сих пор является искусством. Но на конструирование на уровне искусства способны только очень хорошие специалисты. Ремесленники расчёт проводят стандартно - по шаблону. Однако, это хоть и говорит о незаурядности этих хороших специалистов, которые поднимают расчёт до уровня искусства, но одновременно это говорит и о том, что методика данного расчёта является несовершенной.
Если конкретно о реляционных базах данных - то корень проблемы в том, что их теория так и не была завершена. И практика побежала самостоятельно далеко впереди. По поводу чего бедняга Дейт очень переживал. Надеюсь, что хорошее вино помогает ему пережить эту коллизию.
Всякий раз, когда мы слышим об искусстве вне искусства - это говорит о том, что имеется явное технологическое несовершенство, теоретическая и/или методологическая необеспеченность данного направления деятельности. Как говорил товарищ Джугашвили: "Нет ничего практичнее хорошей теории".

Добавлено через 2 часа 44 минуты
Пока не понятно сколько нужно выпить для выработки своих правил.
Вот неожиданное интересное предложение (Modern SQL Style Guide) :

Do not SHOUTCASE or "Sentence case" SQL keywords (e.g., prefer select, not SELECT or Select). SHOUTCASED SQL is an anachronism, and is not appropriate for modern SQL development. Using lowercase keywords is preferred because:

UPPERCASE words are harder to type and harder to read.
SQL syntax is not case-sensitive, and thus lowercase keywords work correctly in all variants of SQL
No other modern languages use ALLCAPS keywords.
Modern editors color code SQL keywords, so there is not a need to distinguish keywords by casing.
If you are in an environment where your keywords are not colored (i.e. as a string in another language), using a river for formatting provides a similar benefit of highlighting important keywords without resorting to CAPS.
UPPERCASE IS ASSOCIATED WITH SHOUTING WHEN SEEN IN TEXT, IS HARD TO READ, AND MAKES SQL FEEL MORE LIKE COBOL THAN A MODERN LANGUAGE.
If the SQL script you are editing already uses SHOUTCASE keywords, match that style or change all keywords to lowercase. Favor bending the rules for the sake of consistency rather than mixing styles.

Добавлено через 31 минуту
А тут ретрограды да ещё и категорически против больших букав в названиях таблиц и столбцов MySQL 26.1.1 Coding Style

Write SQL statements in the style of the MySQL Reference Manual

- SQL keywords and reserved words: uppercase

- Identifiers (table names, column names, etc.): lowercase

Ignore this guideline if your intent is to check the processing of mixed lettercases ;-)

@Gluck99 · 06.09.2022, 01:51

Сообщение от titan4ik

А тут ретрограды да ещё и категорически против больших букав в названиях таблиц и столбцов

Да, "ретрограды" пишут, что зарезервированные слова и функции должны быть в верхнем регистре: SQL keywords and reserved words: uppercase. Собственно, достаточно посмотреть на их собственные примеры кода в руководстве.
Так что я поддерживаю "ретроградов" из MySQL, кроме их мнения насчет имен полей, которые они рекомендуют писать в нижнем регистре. Вот тут уж нет, поля - только горбатой нотацией.

Модерновые и продвинутые гитхабовцы с крашенными волосами пусть свернут своё особо ценное мнение в трубочку и засунут в карман. Суть в том, что ключевые операторы в запросе SELECT/FROM/JOIN/WHERE и т.д. визуально делят код на блоки, делят именно своим выделяющимся размером. Код одним нижним регистром становится плохо читаемым в случае большого количества подзапросов (т.е. SELECT'ов). Особенно если запрос у вас не подсвечен синтаксически, потому что вы его пишите как строку не в SQL-редакторе, а в редакторе PHP/Python/C# и т.д.

@titan4ik · 06.09.2022, 02:02 **[ТС]**

Gluck99, спасибо! Ну вот, теперь я почти всё уже знаю.

@pincet · 06.09.2022, 15:15

Не по теме:

Сообщение от titan4ik

бедняга Дейт очень переживал

бедняга походу тут один

@titan4ik · 06.09.2022, 17:33 **[ТС]**

Сообщение от titan4ik

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

Сообщение от Аватар

использую namep -fнаименование полное, names - сокращенное,

Упс... Но Names - ключевое слово SQL.
Я щас вам тут наведу порядок

Добавлено через 10 минут
В SQL Names и Named ключевые. А вот Name - не ключевое в SQL. Но может быть (или не быть) ключевым в диалектах.

Добавлено через 1 минуту
Список ключевых слов SQL - https://en.wikipedia.org/wiki/SQL_reserved_words
Список зарезервированных ключевых слов ANSI SQL (92, 99 and 2003), MySQL версий с 3 по 5.x, PostgreSQL 8.1, MS SQL Server 2000, MS ODBC и Oracle 10.2 - тут

@Grossmeister · 07.09.2022, 09:38

Сообщение от titan4ik

Oracle

В Oracle список ключевых слов содержится во view v$reserved_words. В Ora12 ключевые name и named

@titan4ik · 08.09.2022, 13:46 **[ТС]**

Спасибо всем, кто помог мне, а именно: qwertehok, Grossmeister, Аватар, Gluck99, а также, несравненной shanemac51, в разработке собственного корпоративного стандарта именования в SQL. По сути, после долгих колебаний, несмотря на обаятельную ремарку от сударыни shanemac51, за основу была взята информация, полученная в ходе продолжительного допроса с пристрастием мистера Gluck99. Спасибо, также, моему коту, который во время написания этого стандарта почти не наступал на клавиатуру. После тяжелой и продолжительной ~~болезни~~ работы предоставляю на суд общественности первый черновой вариант стандарта:

Кликните здесь для просмотра всего текста

Стиль SQL корпорации BigHard (Like SQLite)

Именование таблиц и полей (столбцов)

1. Проверять имя на зарезервированность в качестве ключевого слова.

2. Для имён использовать только латиницу, цифры и нижнее подчёркивание (не в конце имени). На первой позиции должна быть буква.

3. Имена таблиц
- Только строчными (маленькими) буквами.
- Разделитель слов — нижнее подчеркивание.
- Префиксы допускаются через нижнее подчеркивание (не злоупотреблять) для разделения таблиц по стандартным
группам. Например, префикс c_ для таблиц справочников или cc_ для справочников глобального толка (валюта,
страны).
- Допускается возможность неких стандартных суффиксов через нижнее подчеркивание, например,
отражающих структуру данных (некие группировки сущностей) модели (аналогично такому стилю в коде c#, уже
принятому в корпорации BigHard).

4. Имена полей
- В нотации PascalCase (как в коде c#).
- Допускаются некоторые стандартные суффиксы (как ID) слитно (в нотации PascalCase).
- Полям, которые присущи по своему содержанию многим сущностям (таблицам),
добавлять имя сущности — CareName.
- Суррогатный первичный ключ именовать обезличенно — ID.
- Внешние ключи именовать по имени сущности с суффиксом ID (слитно в нотации PascalCase ) — CarID.
- P.S.
--- Допускается в отдельных случаях, для сокращения текста, при именовании полей использовать некие
собственные «стандартные» условные суффиксы в нотации PascalCase. Например, как вариант, для обозначения
полного имени (нормального) - P, сокращенного - S, супер сокращенного - SS, длинного имени - L, аббревиатуры
наименования – A. Соответственно — CarNameP, CarNameS, CarNameSS. CarNameL, CarNameA.
--- ? - Не отрицается возможность неких стандартных суффиксов через нижнее подчеркивание, например,
отражающих структуру данных (некие группировки сущностей) модели (аналогично такому стилю в коде c#, уже
принятому в корпорации BigHard).
--- ??? - Префиксы - ??? - представляются нежелательными.

Исходные материалы:
1. Джо Селко - Имена и элементы данных - Глава из книги “Стиль программирования Джо Селко на SQL” - https://www.rsdn.org/article/db/sqlnames.xml
2. Саймон Холиуэлл (Simon Holywell) «Руководство по стилю SQL · SQL Style Guide» - ссылка на русский вариант.
3. Стандарт ISO-11179-4 - https://standards.iso.org/ittf... 004(E).zip
4. Тема на киберфоруме - Правила именования таблиц и столбцов БД
5. Списки зарезервированных ключевых слов SQL
- SQL - https://en.wikipedia.org/wiki/SQL_reserved_words
- SQL (плюс диалекты) — список
- SQLite - https://www.sqlite.org/lang_keywords.html

@titan4ik · 08.09.2022, 23:01 **[ТС]**

Ошибся в названии своей корпорации. Правильно так - MacroHard.
И не "предоставляю", а "представляю". Тьфу. Сколько опечуток. Ну, как и в любом стандарте.

@titan4ik · 14.03.2023, 17:44 **[ТС]**

Всем спасибо ещё раз. Появилась возможность (функционал этот мне возвертали) "спасибки" расставить - расставил.

@titan4ik · 20.04.2023, 20:56 **[ТС]**

Ещё одно мнение. Из очень хорошей, как мне кажется, книги - "Использование SQLite" Джей А. Крейбич (2010г)

Последний комментарий по именам ключей. Часто возникает соблазн назвать общее поле идентификатора чем-нибудь простым, например id. В конце концов, если у вас есть таблица employee, может показаться несколько излишним называть первичный ключ employee_id; вы получаете множество ссылок на столбцы, которые читают employee.employee_id, когда кажется, что employee.id достаточно ясен.

Что ж, само по себе это достаточно ясно, но первичные ключи, как правило, отображаются в других таблицах как внешние ключи. В то время как employee.employee_id может быть немного избыточным, имя task_assignment.employee_id - нет. Это имя также дает вам важные подсказки о функции столбца (внешний ключ) и о том, на какую таблицу и столбец он ссылается (столбец employee_id, который является столбцом PK таблицы employee). Использование одного и того же имени для первичных и внешних ключей делает внутреннее значение и связь намного более очевидными. Он также позволяет использовать ярлыки, такие как синтаксис NATURAL JOIN или JOIN...USING( ). Обе эти формы требуют, чтобы совпадающие столбцы имели одно и то же имя.

Использование более явного имени также позволяет избежать проблемы наличия нескольких таблиц, каждая из которых имеет столбец с именем id. Такое общее название может несколько запутать, если вы объедините три или четыре таблицы. Хотя это и не обязательно, префикс каждого имени столбца, сохранение уникальных имен первичных ключей в базе данных (и использование одного и того же имени для внешних ключей) может сделать замысел дизайна базы данных намного более ясным.

@VinniPuh · 20.04.2023, 21:41

Сообщение от titan4ik

...Часто возникает соблазн назвать общее поле идентификатора чем-нибудь простым, например ...id

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

Добавлено через 3 минуты
titan4ik, Думаю, что ты не должен стесняться, а в в вопросах праведных решений - Пороть - Правду - матку.
Наши однозначно победять.

@titan4ik · 20.04.2023, 21:47 **[ТС]**

Я понял. И ещё отдельно хочу порекомендовать всем эту книгу "Использование SQLite" Джей А. Крейбич (2010г). Потому что автор явно умный чувак. Он некоторые важные вещи очень скупо, но точно поясняет. Это дорогого стоит. Она полезна и тем, кто просто БД интересуется и SQL, а не только по части конкретно SQLite.

Добавлено через 1 минуту
Возможно, что её можно порекомендовать, как первую книгу по БД. Именно её, а не книгу тоже умного Дейта.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

@titan4ik Заблокирован

	Правила именования таблиц и столбцов БД 01.09.2022, 13:00. Показов 7328. Ответов 55 Метки нет (Все метки) Господа, товарищи, граждане, помогите! В части правил именования таблиц и столбцов в интернете царит жуткий разнобой. Нет ли таких правил, которые стали хотя бы относительно устоявшимся стандартом для всех, или для вашей компании, или для вас лично? Будьте так добры, дайте ссылку на них. P.S. Не хочется без крайней нужды изобретать велосипед. Точнее - попытался изобрести и уже вижу, что колеса не вполне круглые 0

@titan4ik Заблокирован
	06.09.2022, 02:02 [ТС]
	Gluck99, спасибо! Ну вот, теперь я почти всё уже знаю. 0

@titan4ik Заблокирован
	08.09.2022, 13:46 [ТС]
	Спасибо всем, кто помог мне, а именно: qwertehok, Grossmeister, Аватар, Gluck99, а также, несравненной shanemac51, в разработке собственного корпоративного стандарта именования в SQL. По сути, после долгих колебаний, несмотря на обаятельную ремарку от сударыни shanemac51, за основу была взята информация, полученная в ходе продолжительного допроса с пристрастием мистера Gluck99. Спасибо, также, моему коту, который во время написания этого стандарта почти не наступал на клавиатуру. После тяжелой и продолжительной ~~болезни~~ работы предоставляю на суд общественности первый черновой вариант стандарта: Кликните здесь для просмотра всего текста Стиль SQL корпорации BigHard (Like SQLite) Именование таблиц и полей (столбцов) 1. Проверять имя на зарезервированность в качестве ключевого слова. 2. Для имён использовать только латиницу, цифры и нижнее подчёркивание (не в конце имени). На первой позиции должна быть буква. 3. Имена таблиц - Только строчными (маленькими) буквами. - Разделитель слов — нижнее подчеркивание. - Префиксы допускаются через нижнее подчеркивание (не злоупотреблять) для разделения таблиц по стандартным группам. Например, префикс c_ для таблиц справочников или cc_ для справочников глобального толка (валюта, страны). - Допускается возможность неких стандартных суффиксов через нижнее подчеркивание, например, отражающих структуру данных (некие группировки сущностей) модели (аналогично такому стилю в коде c#, уже принятому в корпорации BigHard). 4. Имена полей - В нотации PascalCase (как в коде c#). - Допускаются некоторые стандартные суффиксы (как ID) слитно (в нотации PascalCase). - Полям, которые присущи по своему содержанию многим сущностям (таблицам), добавлять имя сущности — CareName. - Суррогатный первичный ключ именовать обезличенно — ID. - Внешние ключи именовать по имени сущности с суффиксом ID (слитно в нотации PascalCase ) — CarID. - P.S. --- Допускается в отдельных случаях, для сокращения текста, при именовании полей использовать некие собственные «стандартные» условные суффиксы в нотации PascalCase. Например, как вариант, для обозначения полного имени (нормального) - P, сокращенного - S, супер сокращенного - SS, длинного имени - L, аббревиатуры наименования – A. Соответственно — CarNameP, CarNameS, CarNameSS. CarNameL, CarNameA. --- ? - Не отрицается возможность неких стандартных суффиксов через нижнее подчеркивание, например, отражающих структуру данных (некие группировки сущностей) модели (аналогично такому стилю в коде c#, уже принятому в корпорации BigHard). --- ??? - Префиксы - ??? - представляются нежелательными. Исходные материалы: 1. Джо Селко - Имена и элементы данных - Глава из книги “Стиль программирования Джо Селко на SQL” - https://www.rsdn.org/article/db/sqlnames.xml 2. Саймон Холиуэлл (Simon Holywell) «Руководство по стилю SQL · SQL Style Guide» - ссылка на русский вариант. 3. Стандарт ISO-11179-4 - https://standards.iso.org/ittf... 004(E).zip 4. Тема на киберфоруме - Правила именования таблиц и столбцов БД 5. Списки зарезервированных ключевых слов SQL - SQL - https://en.wikipedia.org/wiki/SQL_reserved_words - SQL (плюс диалекты) — список - SQLite - https://www.sqlite.org/lang_keywords.html 0

@titan4ik Заблокирован
	08.09.2022, 23:01 [ТС]
	Ошибся в названии своей корпорации. Правильно так - MacroHard. И не "предоставляю", а "представляю". Тьфу. Сколько опечуток. Ну, как и в любом стандарте. 0

@titan4ik Заблокирован
	14.03.2023, 17:44 [ТС]
	Всем спасибо ещё раз. Появилась возможность (функционал этот мне возвертали) "спасибки" расставить - расставил. 0

@titan4ik Заблокирован
	20.04.2023, 21:47 [ТС]
	Я понял. И ещё отдельно хочу порекомендовать всем эту книгу "Использование SQLite" Джей А. Крейбич (2010г). Потому что автор явно умный чувак. Он некоторые важные вещи очень скупо, но точно поясняет. Это дорогого стоит. Она полезна и тем, кто просто БД интересуется и SQL, а не только по части конкретно SQLite. Добавлено через 1 минуту Возможно, что её можно порекомендовать, как первую книгу по БД. Именно её, а не книгу тоже умного Дейта. 0