Инженеры не любят писать - известный факт. Это относится не только к документации, различным отчетам, электронным письмам, комментариям к своему коду, но даже и наименованиям сущностей их атрибутов в этом самом коде. Вот на последнем остановлюсь подробнее.

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

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

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

Правила хорошего тона в SQL:

  • Применяйте для именования сущностей и их атрибутов (таблиц и полей) змеиный регистр (snake_case), то есть если наименование состоит из нескольких слов, то разделяйте их символом подчеркивания (_) вместо пробела и все слова пишите в нижнем регистре. Например, таблица rental_equipment, поле first_name.

  • Именуйте основной ключ (primary key) по принципу - название сущности в единственном числе, нижнее подчёркивание, id - <table_name>_id. Например, для таблицы products поле с основным ключом именуйте product_id, а не просто id. Это значительно упростит чтение кода и облегчит понимание, идентификатор какой сущности используется в конкретном случае.

  • Соблюдайте последовательность в наименовании основного ключа (primary key). Например, для таблицы customers, основной ключ должен называться customer_id и никак не user_id.

  • Не используйте сокращения для псевдонимов (alias-ов). Понятно, что с ними получается короче, но лучше делайте упор на удобочитаемости кода, нежели на краткости. Например, не используйте для таблицы equipment псевдоним equip или для products псевдоним p.

  • Добавляйте к именам атрибутов сущностей (полям таблиц) с булевым типом данных префикс is_ или has_.

  • Именуйте атрибуты сущностей (поля таблиц) с типом данных дата по принципу - название название события, нижнее подчёркивание, id - <event>_id. Например, created_date.

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