Comments 21
Если ваше имя атрибута содержит более 1 слова, отделите его snake_case. [...] Улучшает читабельность
… почему?
(Собственно, дальше можно такие же вопросы задавать, но одного достаточно)
тут на хабре была статья, где приводились результаты отслеживания фокуса внимания (куда направлено зрение) для разных способов именования переменных. В случае 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.
оракл, например, любит переводить названия полей итп из строчных в заглавные. При этом camelCase превращается в нечитаемый CAMELCASE. Видимо это традиции с давних времен, и админы бд уже привыкли разделять слова подчеркиванием.
Правило 14 противоречит правилам 16-18, как так?!
Вот так и вижу, что разраб на прикрепленном за компом переключился на рабочий стол
Мне кажется проще не person_id, а id_person - так сразу видно, что это идентификатор. И если располагать все идентификаторы сразу вначале, то и читать такую таблицу проще...
id
id_person
id_table
id_еще_одна
уже давно существует https://www.sqlstyle.guide/ в том числе там есть и переводы и очень хорошие пояснения зачем и почему, взять его за основу очень логично.
Под ним настоящий заголовок: «18 лучших практик создания простых и последовательных имен»
Заголовок не соответствует статье. По моему, лучше убрать заголовок, и оставить в качестве заголовка подзаголовок. В статье говорится только про имена. По заголовку и следующему за ним подзаголовку кажется, будто планировалось раскрыть и другие темы, но их нет. Вообще, термин «чистая база данных» можно понять по разному, но очевидно это очень много всего, помимо имён. Та же нормализация, хотя бы.
О 9-ом пункте, открываем документацию и в примерах таблицы названы в множественном числе
https://www.postgresql.org/docs/14/sql-createtable.html
Какой-то очень плохой машинный перевод
Если у вашего имени столбца есть время, то суффикс их с _at или _time.
У столбца может быть время?
Не успел отредактировать
В тексте очень много вкусовщины, да так что возникают вопросы почти к каждому из упомянутых пунктов. Поэтому побуду занудой и озвучу их все.
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.
Такое ощущение, что автор не замарачивался с переводом фразы, или не отредактировал поток сознания. Потому что в целом совет дельный, но не читаемый.
От себя добавлю привычку, которую я выработал на текущем месте, а именно один-два дополнительных символа в начале названия обьекта.
t_ -- это таблица
v_ -- это вью
m_ -- material view
tv_ -- таблица с результатом выполнения тяжелой вью
-- когда у вас нет технической возможности
-- или прав для создания material view
fn_ -- функция
p_ -- процедураПреимущества по началу не очевидны, но так как мы как правило читаем слева на право, то начав читать название таблицы или вью, мы уже предполагаем что это за обьект, и в некоторых случаях догадываемся, как он формируется. Но соглашусь, не всем нравится.
Как создать чистую базу данных