21.02.2022 17:10
KOTELOV 19 3200 Источник

18 лучших практик создания простых и последовательных имен

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

Терминология

Таблица: это набор данных

Первичный ключ: Это уникальный идентификатор таблицы

Атрибут: означает свойство ваших данных. Например, name.user

Тип данных: Типы данных представляют различные типы ваших данных. Например-string, int, timestamp и т. Д.

1. Слова должны быть разделены подчеркиванием

Если ваше имя атрибута содержит более 1 слова, отделите его snake_case. Не используйте camelCase или любой другой случай для согласованности.

Плохо

wordcount или WordCount

Хорошо

word_count

Причина

  • Улучшает читабельность

  • Имена могут стать более независимыми от платформы

2. Типы данных не должны быть именами

Никогда не используйте типы данных в качестве имени столбца. Это происходит в основном для параметров метки времени. Дайте ему осмысленное имя.

Плохо

timestamp or text

Хорошо

created_at or description

Причина

  • Использование типов данных может создать путаницу на другом конце приложения.

  • Предоставление собственного имени дает больше контекста для использования параметра.

3. Имена атрибутов должны быть строчными

Не используйте имена в верхнем регистре для своих атрибутов.

Плохо

Description

Хорошо

description

Причина

  • Позволяет избежать путаницы с ключевыми словами SQL в верхнем регистре

  • Это может улучшить скорость набора текста

4. Напишите полные слова

Не пытайтесь сократить имена столбцов ради пространства или любой другой логики. Старайтесь быть как можно более явными.

Плохо

mid_name

Хорошо

middle_name

Причина

Это правило способствует самодокументированному дизайну

5. Но используйте общие сокращения

Исключение из правила-4-это когда у вас есть широко распространенная аббревиатура. В таких ситуациях выбирайте короткий.

Хорошо

i18n

Но если вы окажетесь в замешательстве, перейдите к полному имени. Это инвестиции, которые вы делаете на будущее.

6. Избегайте наличия чисел в имени столбца

Верьте или нет, я видел это достаточно. Никогда не имейте чисел в имени столбца.

Плохо

address1 , address2

Хорошо

primary_address, secondary_address

Причина

Это признак очень плохой нормализации на вашем конце. Поэтому старайтесь избегать этого.

7. Используйте короткие имена таблиц

Будьте очень осторожны при именовании таблиц, потому что длинные имена таблиц могут иметь огромное плохое влияние в будущем.

Плохо

site_detail

Хорошо

site

Причина

Короткие имена таблиц помогут вам при создании реляционных столбцов и связывающих таблиц.

8. Ищите зарезервированные слова

В каждой базе данных есть несколько зарезервированных слов. Изучайте их и избегайте.

Плохо

user lock table etc

Список зарезервированных слов для некоторых популярных баз данных

9. Сингулярные имена для таблиц

Всегда старайтесь использовать единственные имена для таблиц. Это спорный вопрос, и у разных людей разные мнения. Но придерживайтесь одного.

Плохо

users and orders

Хорошо

user and order

Причина

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

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

10. Таблицы ссылок должны иметь алфавитный порядок

При создании таблицы соединений объедините имена двух таблиц в алфавитном порядке.

Плохо

book_author

Хорошо

author_book

11. Имена столбцов в единственном числе

Обычно это лучшая практика, если вы не нарушаете правила нормализации данных.

Плохо

books

Хорошо

book

12. Имя первичного ключа

Если это один столбец, то он должен быть назван как id

CREATE TABLE order (
 id bigint PRIMARY KEY,
 order_date date NOT NULL
);

13. Имя внешнего ключа

Это должно быть имя другой таблицы и упомянутого поля. Например, если вы ссылаетесь на person внутри вашего team_member таблица, то вы можете сделать это так.

CREATE TABLE team_member (
 person_id bigint NOT NULL REFERENCES person(id),
);

14. Не указывайте в конце имен столбцов типы хранимых в них данных

Нет смысла суффиксировать имена столбцов типами данных. Избегайте этого.

Плохо 

name_tx

Хорошо

name

15. Индексы должны иметь как имя таблицы, так и столбца

Если вы создаете индекс, за именем таблицы следуют имена столбцов, на которые вы ссылаетесь 

CREATE TABLE person (
 id bigserial PRIMARY KEY,
 first_name text NOT NULL,
 last_name text NOT NULL,
);
CREATE INDEX person_ix_first_name_last_name ON person (first_name, last_name);

16. Имена столбцов типа даты

Суффикс ваших имен столбцов типа даты с _on или _date.

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

Хорошо

updated_on или updated_date

17. Имена столбцов типа даты и времени

Если у вашего имени столбца есть время, то суффикс их с _at или _time.

Например, если вы хотите сохранить время заказа, то

Плохо

ordered

Хорошо

ordered_at or order_time

18. Имена столбцов логического типа

Если у вас есть имена столбцов логического типа, то префикс их is_ или has_.

Хорошо

is_admin или has_membership

Заключение

Если вы уже работаете над проектом, придерживайтесь соглашения, которому уже следует проект. Потому что

Единственное, что хуже плохого соглашения, - это несколько соглашений

Но если вы изучаете или разрабатываете базу данных с нуля, имея в виду эти правила, вы пройдете долгий путь.

Каковы ваши мысли? Есть ли правило, с которым вы не согласны? Я более чем рад продуктивному разговору в разделе комментариев!

Хорошего дня! 

Комментарии (19)


  1. lair
    21.02.2022 17:12
    #24101625
    +1

    Если ваше имя атрибута содержит более 1 слова, отделите его snake_case. [...] Улучшает читабельность

    … почему?


    (Собственно, дальше можно такие же вопросы задавать, но одного достаточно)


    1. gsaw
      21.02.2022 18:34
      #24101935
      +1

      тут на хабре была статья, где приводились результаты отслеживания фокуса внимания (куда направлено зрение) для разных способов именования переменных. В случае snake_case требовалось меньше времени, что бы усвоить название переменной, чем с camelCase.

      https://habr.com/en/company/epam_systems/blog/517398/

      Рисунок 12. Части траекторий движения глаз при корректном опознании underscore и camelCase идентификаторов, состоящих из трех слов

      По личному опыту, думаю, что так и есть. Проще усвоить значение переменной, к примеру second_worker_adress чем secondWorkerAdress.

      В javascript и для идентификаторов в базе я использую snake_case, в java camelCase, но только потому, что это стандарт. Все редакторы, тот же lombok по умолчанию используют camel case.


      1. lair
        21.02.2022 18:39
        #24101957

        По личному опыту, думаю, что так и есть. Проще усвоить значение переменной, к примеру second_worker_adress чем secondWorkerAdress.

        … а как это работает в смешанных средах? Где и такие, и такие имена?


    1. alexxisr
      21.02.2022 19:57
      #24102189

      оракл, например, любит переводить названия полей итп из строчных в заглавные. При этом camelCase превращается в нечитаемый CAMELCASE. Видимо это традиции с давних времен, и админы бд уже привыкли разделять слова подчеркиванием.


  1. vilgeforce
    21.02.2022 17:15
    #24101637

    Правило 14 противоречит правилам 16-18, как так?!


    1. Vladislav_Dudnikov
      21.02.2022 17:25
      #24101693
      +2

      Мне кажется никакого противоречия нет, потому что суффикс _at (например) не указывает на конкретный тип данных, а скорее на класс объекта (конечно, в итоге это сводиться к некотором небольшому количеству конкретных типов, но всё же).


  1. feoktant
    21.02.2022 17:48
    #24101789

    Пункт 9 появляется из-за пункта 12. Если ключ именуется как table_id, никаких проблем нет. Такое именование не обрело популярности, хотя под него даже есть специальный синтаксис using во многих rdbms.


  1. xakepmega
    21.02.2022 19:51
    #24102163

    Вот так и вижу, что разраб на прикрепленном за компом переключился на рабочий стол


  1. virtusha
    22.02.2022 01:26
    #24102793

    Мне кажется проще не person_id, а id_person - так сразу видно, что это идентификатор. И если располагать все идентификаторы сразу вначале, то и читать такую таблицу проще...

    • id

    • id_person

    • id_table

    • id_еще_одна


    1. Dek4nice
      22.02.2022 07:14
      #24103039

      система именования строится по принципу расположения имён в порядке их подчинения от общего к частному:
      база → таблица → атрибут → тип


    1. IvanPetrof
      22.02.2022 08:56
      #24103279
      +1

      В своих проектах использую поле id в качестве первичного ключа и поля table_id в качестве foreign key.
      При этом соединения таблиц выглядят единообразно 

      table.person_id = person.id 
and person.dept_id = dept.id

      Таким образом не нужно задумываться где писать id (в начале или в конце).


  1. smple
    22.02.2022 01:36
    #24102811

    уже давно существует https://www.sqlstyle.guide/ в том числе там есть и переводы и очень хорошие пояснения зачем и почему, взять его за основу очень логично.


  1. Cryvage
    22.02.2022 02:08
    #24102851
    +3

    Заголовок статьи: «Как создать чистую базу данных»
    Под ним настоящий заголовок: «18 лучших практик создания простых и последовательных имен»
    Заголовок не соответствует статье. По моему, лучше убрать заголовок, и оставить в качестве заголовка подзаголовок. В статье говорится только про имена. По заголовку и следующему за ним подзаголовку кажется, будто планировалось раскрыть и другие темы, но их нет. Вообще, термин «чистая база данных» можно понять по разному, но очевидно это очень много всего, помимо имён. Та же нормализация, хотя бы.


    1. hello_my_name_is_dany
      22.02.2022 05:03
      #24102967
      +1

      Я так вообще подумал, что будет реализация какой-то СУБД, а тут про имена...


  1. Vetal130
    22.02.2022 09:12
    #24103353
    +1

    О 9-ом пункте, открываем документацию и в примерах таблицы названы в множественном числе
    https://www.postgresql.org/docs/14/sql-createtable.html


  1. KislyFan
    22.02.2022 18:04
    #24105493

    Какой-то очень плохой машинный перевод

    Если у вашего имени столбца есть время, то суффикс их с _at или _time.

    У столбца может быть время?


    1. KislyFan
      22.02.2022 19:54
      #24105729

      Не успел отредактировать


  1. KislyFan
    22.02.2022 19:53
    #24105725
    +1

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

    1. Слова должны быть разделены подчеркиванием
    Плохо wordcount или WordCount

    Один из действительно полезных советов. Например ORACLE очень любит создавать регистрозависимые имена столбцов, и вы не сможете к ним обращаться иначе, чем MYTABLE."WordCount".

    2. Типы данных не должны быть именами
    8. Ищите зарезервированные слова

    Классическая тавтология. По факту это одно правило "не использовать зарезервированные ключевые слова и названия функций и таблиц". Например если вы в ORACLE создадите тустую таблицу ALL_OBJECTS, то некоторые клиенты (например ADS) перестанут выдавать вам список обьектов в этой БД.

    3. Имена атрибутов должны быть строчными

    А может быть надо отталкиваться от предпочтений конкретной БД ? Как заметил @alexxisr ORACLE очень любит приводить названия к верхнему регистру. Более того, из моего опыта, если вы обращаетесь из MSSQL/TSQL через функционал OPENQUERY, то можете получить ошибку, если запрос будет написан нижнем регистре или camelCase форматировании.

    4. Напишите полные слова
    7. Используйте короткие имена таблиц

    Вы либо крестик снимите, либо трусы наденьте. Пишите полные читаемые имена таблиц и столбцов, чтобы следующий забавный перснаж, который будет работать с ней не задавался вопросом "а что это за данные".

    6. Избегайте наличия чисел в имени столбца

    Неправильно сформулированный совет. Нужно было сформулировать как "Не назначайте имена столбцов которые отличаются только цифровыми постфиксами, если числа не имеют особого значения". К примеру address1 , address2 это действительно плохой пример, но region23, region16, region74 будут более приемлимыми, т.к. цифра явно является автомобильным кодом региона (опустим тут момент, что вообще создавать отдельный столбец для каждого такого примера - плохая идея, привел исключительно для примера).

    Что гораздо важнее, оставляйте время для документирования и внесения комментариев к таблицам и столбцам. В случае генерирования DDL они также будут выгружены вместе со всей остальной информацией.

    9. Сингулярные имена для таблиц

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

    10. Таблицы ссылок должны иметь алфавитный порядок
    author_book, но не book_author

    Я думаю, что это чистая ничем не подкрепленная вкусовщина.. но если вам как-то хочется иметь систему, то гораздо логичнее будет порядок source-target. Минус в том, что если вдруг кто-то перестанет соблюдать порядок, то можно начать путаться.

    11. Имена столбцов в единственном числе

    Если поле содержит информацию с разделителем, а обработка этих данных не предполагается (только для чтения), то почему бы и нет?

    14. Не указывайте в конце имен столбцов типы хранимых в них данных

    Как правило да.. но наиболее частое исключение, это добавление сокращенного названия типа к имени столбца содержащего дату. В этом случае массово используют суффикс _dt или _ts.

    16. Имена столбцов типа даты
    Если у вашего имени столбца есть время, то суффикс их с _at или _time.

    Такое ощущение, что автор не замарачивался с переводом фразы, или не отредактировал поток сознания. Потому что в целом совет дельный, но не читаемый.


  1. KislyFan
    22.02.2022 20:08
    #24105765

    От себя добавлю привычку, которую я выработал на текущем месте, а именно один-два дополнительных символа в начале названия обьекта.

    t_ -- это таблица
v_ -- это вью

m_ -- material view
tv_ -- таблица с результатом выполнения тяжелой вью
    -- когда у вас нет технической возможности 
    -- или прав для создания material view

fn_ -- функция
p_	-- процедура

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