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

Комментарии 21

Жму руку тому человеку, которому понравится переключать раскладку по сто раз во время написания запросов.

Это вопрос, скорее, религиозного характера, поэтому объяснение в тексте под спойлером. Но для заведомо однозначного понимания «что это за ...» я привел названия именно «по-русски».

Это объективно снижает эффективность. Потому что:


  • для написания запроса полностью на латинице вам нужно написать только строку запроса, а для запросов с чем-то не из ASCII вам нужно для каждого поля ввести две кавычки, плюс соблюсти регистр символов, плюс переключить раскладку минимум два раза. Если работа программиста заключается в основном в том, чтобы работать с базой данных — при таком подходе проще сразу застрелиться (это уже субьективно).
  • не все ЯП хорошо относятся к кириллическим символам в названиях переменных/полей/функций. Условный мессенджер — это не табличка в БД, а полноценная программа. Безусловно, если использовать что-то вроде PostgREST и хранимых процедур на pl/pgsql, то с этим проблем не будет. Поэтому при написании кода для самого мессенджера для целей сериализации придётся либо проводить транслитерацию русских переменных, либо ещё как-то извращаться, если целевой язык не слишком хорошо поддерживает кириллицу в коде.
Мы же говорим о примере моделирования БД. Для целей статьи — то есть усвоения информации человеком — лучше уж кириллицей.
Ведь даже в разговорном общении разработчики скажут «прочитай такие-то сообщения по такому-то индексу», а не «произведи SELECT записей из таблицы messages».
Никто ведь не заставляет использовать такие названия полей и таблиц при разработке в конкретных условиях, тем более в условиях ограничений ЯП.

С таким подходом очень сложно в интернациональных компаниях. Доминирующее большинство разработчиков прекрасно читают и воспринимают на слух английские названия таблиц и т.п. А вот кириллица в коде у меня стойко ассоциируется с 1С.

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

Вы говорите


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

А потом


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

Никто и абстрактные мессенджеры в принципе не разрабатывает. Статью написать и забыть, конечно, и правда можно с такими описаниями сущностей, но раз уж большинство разработчиков таким не занимаются, то идти поперёк того, что используется и понимается всеми — довольно странно и непривычно.


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

Между моделью решения конкретной прикладной задачи и конкретной ее реализацией есть определенная разница. В статье я писал про первое.
идти поперёк того, что используется и понимается всеми — довольно странно и непривычно
В реляционной алгебре, из которой весь SQL вышел, «всеми используются и понимаются» совсем другие операции для решения тех же задач — но таки мы пользуемся не ими, а SQL, и между собой говорим «по-человечьи».
Но непривычно — да, возможно. Но это «на вкус и цвет» — для меня, например, Crow's Foot/IDEF1X кажутся чрезмерно сложными для описания простых вещей.

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

Не смог читать мешанину из русских и английских слов…
Вот так — приятнее для глаз?
Проблема, что всегда есть шанс нарваться на reserved word.

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

Напрмер message_id или user_id. Трагичное попадание на ключевое слово может случиться при апргейде базы данных, увы.
Или при миграции на другую СУБД — назвать uuid-поле вполне безобидным именем rowid в PostgreSQL, и словить артефакты в Oracle… или ctid в обратную сторону.

При миграции на другую СУБД вопросы именования полей будут далеко не самыми сложными и интересными 8)

Кто мешает держать перед глазами табличку ключевых слов диалекта (текущая): https://www.postgresql.org/docs/current/sql-keywords-appendix.html
По моему скромному мнению вероятность использовать такое слово вполне себе устремляется к нулю с таким подходом.
Лично я вполне себе такое практикую. И горя не знаю. И да, при использовании ключевых слов без кавычек ПГ ругается страшной руганью и не позволяет создать объект, который либо сам называется ключевым словом, либо в своём составе содержит ключевое слово в качестве названия подобъекта (например, наименование столбца в таблице).
Обновление? А вы аннотации к новой версии не читаете? Правда?

Даже не «внезапно нарваться на reserved при обновлении», а нарваться при переносе бизнес-сущностей в конкретные названия таблиц. Вроде и хочешь «честно» назвать таблицу user или group или столбец copy — а нет, и начинаются костыли…
Обновление? А вы аннотации к новой версии не читаете? Правда?
А как чтение release notice поможет застраховаться от необходимости переназвать объекты и переписать запросы, если вдруг возникнет конфликт?
Вроде и хочешь «честно» назвать таблицу user или group или столбец copy — а нет, и начинаются костыли…

Вот именно для этого я держу перед глазами указанную ссылку. Костыли — более, чем согласен, но ключевые слова — это ключевые слова. Увы нам.


А как чтение release notice поможет застраховаться от необходимости переназвать объекты и переписать запросы, если вдруг возникнет конфликт?

Вот смотрите: прочитали аннотацию, прослезились, обматерили разработчиков, переименовали то, что нужно, после этого обновились. Хотя бы от косяков от именования не будет после обновления.
Когда аннотация не читается, вероятность ошибки, связанной с именованием объектов, при запуске на обновлённой СУБД существенно выше.

не та ветка комментариев
Вот это вы развели дискуссию не по теме статьи, пунто отлично справляется с раскладкой за частую я забываю в принципе что её нужно переключать. А писать комменты просто чтобы показать какие тут все англоговорящие… ой ну правда вы как малолетки. Реально намного проще воспринимать таблицы с русскими полями. Во вторых зачем планировать миграцию на другую бд когда нибудь в далёком далёкой будущем в далёкой далёкой галактике/ <L Уже выбрана и софт пишем под неё… высасывать проблему из пальца и пытаться тролить этим автора, а не писать объективные комменты по тексту статью… это ребяечество
Статья про проектирование каркаса базы данных. И для описания используется язык SQL. И вот оформление этого самого каркаса тут обсуждается. Предложение называть столбец PK таблицы так же как и саму таблицу уже приводит к некоторому замешательству. Дополнительно в такой БД запросы будут выглядеть как каша из русских и английских слов.
Как пример типичного запроса. При попытке его прочитать у меня вскипает мозг от частоты пререключения языка.
SELECT 
    "Пользователь"."Пол"
  , CAST("ДатаВремя" AS DATE) "Дата"
  , COUNT(1) "КоличествоПользователей"
FROM "Пользователь" 
JOIN "Страна" ON "Пользователь"."Страна" = "Страна"."Страна"
WHERE 
    UPPER("Страна"."Название") = 'РОССИЯ'
    AND "Пользователь"."Пол" IS NOT NULL
GROUP BY "Пользователь"."Пол", CAST("ДатаВремя" AS DATE)
Так-то нет большой беды, если такой запрос аккуратно оформлен:


А нечитаемо-то написать запрос можно независимо от языка и названий:
SELECT 
    "user".sex, dt::date,
    COUNT(1)
FROM "user" JOIN country ON "user".country = country.country_id
WHERE UPPER(country.title) = 'РОССИЯ' AND "user".sex IS NOT NULL
GROUP BY 1,2
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
sbis.ru
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре