Как стать автором
Обновить

Комментарии 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.

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

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

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

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

  • id

  • id_person

  • id_table

  • id_еще_одна

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

НЛО прилетело и опубликовало эту надпись здесь

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

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

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

это же, как вижу, дикий перевод какой-то статьи. "Это признак очень плохой нормализации на вашем конце."

Спасибо! Поправили )

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

Если у вашего имени столбца есть время, то суффикс их с _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_	-- процедура

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории