Комментарии 21
Жму руку тому человеку, которому понравится переключать раскладку по сто раз во время написания запросов.
Это объективно снижает эффективность. Потому что:
- для написания запроса полностью на латинице вам нужно написать только строку запроса, а для запросов с чем-то не из ASCII вам нужно для каждого поля ввести две кавычки, плюс соблюсти регистр символов, плюс переключить раскладку минимум два раза. Если работа программиста заключается в основном в том, чтобы работать с базой данных — при таком подходе проще сразу застрелиться (это уже субьективно).
- не все ЯП хорошо относятся к кириллическим символам в названиях переменных/полей/функций. Условный мессенджер — это не табличка в БД, а полноценная программа. Безусловно, если использовать что-то вроде PostgREST и хранимых процедур на pl/pgsql, то с этим проблем не будет. Поэтому при написании кода для самого мессенджера для целей сериализации придётся либо проводить транслитерацию русских переменных, либо ещё как-то извращаться, если целевой язык не слишком хорошо поддерживает кириллицу в коде.
Ведь даже в разговорном общении разработчики скажут «прочитай такие-то сообщения по такому-то индексу», а не «произведи SELECT записей из таблицы messages».
Никто ведь не заставляет использовать такие названия полей и таблиц при разработке в конкретных условиях, тем более в условиях ограничений ЯП.
С таким подходом очень сложно в интернациональных компаниях. Доминирующее большинство разработчиков прекрасно читают и воспринимают на слух английские названия таблиц и т.п. А вот кириллица в коде у меня стойко ассоциируется с 1С.
Вы говорите
Без понимания прикладной специфики задачи и задаваемых ей ограничений, спроектировать эффективную схему БД для ее решения практически невозможно.
А потом
Никто ведь не заставляет использовать такие названия полей и таблиц при разработке в конкретных условиях
Никто и абстрактные мессенджеры в принципе не разрабатывает. Статью написать и забыть, конечно, и правда можно с такими описаниями сущностей, но раз уж большинство разработчиков таким не занимаются, то идти поперёк того, что используется и понимается всеми — довольно странно и непривычно.
Да и в разговоре зачастую кастомные сущности естественным образом обрастают слегновыми "юзерами" и "месседжами". Чистота русского языка — это хорошо, но с этим можно поупражняться в документации, а работать с переменными на латинице привычнее.
идти поперёк того, что используется и понимается всеми — довольно странно и непривычноВ реляционной алгебре, из которой весь SQL вышел, «всеми используются и понимаются» совсем другие операции для решения тех же задач — но таки мы пользуемся не ими, а SQL, и между собой говорим «по-человечьи».
Но непривычно — да, возможно. Но это «на вкус и цвет» — для меня, например, Crow's Foot/IDEF1X кажутся чрезмерно сложными для описания простых вещей.
Это какой-то просто стратегический фейл именовать сущности на русском. Мало того что задолбаешься раскладку переключать, так еще и кучу кавычек расставлять надо. Не смог читать мешанину из русских и английских слов… Варианты разночтения проще решить документацией или комментариями к столбцам.
Не смог читать мешанину из русских и английских слов…Вот так — приятнее для глаз?
Проблема, что всегда есть шанс нарваться на reserved word.
Спасибо, так гораздо приятнее. Шанс нарваться, конечно, есть всегда. Но почти всегда это проблема вскрывается при прототипировании или при разработке. Проблема дополнительно еще уменьшается, если в именах слобцов зашито указание на тип. Напрмер message_id или user_id. Трагичное попадание на ключевое слово может случиться при апргейде базы данных, увы. Но это уже довольно редкое событие.
Кто мешает держать перед глазами табличку ключевых слов диалекта (текущая): https://www.postgresql.org/docs/current/sql-keywords-appendix.html
По моему скромному мнению вероятность использовать такое слово вполне себе устремляется к нулю с таким подходом.
Лично я вполне себе такое практикую. И горя не знаю. И да, при использовании ключевых слов без кавычек ПГ ругается страшной руганью и не позволяет создать объект, который либо сам называется ключевым словом, либо в своём составе содержит ключевое слово в качестве названия подобъекта (например, наименование столбца в таблице).
Обновление? А вы аннотации к новой версии не читаете? Правда?
Обновление? А вы аннотации к новой версии не читаете? Правда?А как чтение release notice поможет застраховаться от необходимости переназвать объекты и переписать запросы, если вдруг возникнет конфликт?
Вроде и хочешь «честно» назвать таблицу user или group или столбец copy — а нет, и начинаются костыли…
Вот именно для этого я держу перед глазами указанную ссылку. Костыли — более, чем согласен, но ключевые слова — это ключевые слова. Увы нам.
А как чтение release notice поможет застраховаться от необходимости переназвать объекты и переписать запросы, если вдруг возникнет конфликт?
Вот смотрите: прочитали аннотацию, прослезились, обматерили разработчиков, переименовали то, что нужно, после этого обновились. Хотя бы от косяков от именования не будет после обновления.
Когда аннотация не читается, вероятность ошибки, связанной с именованием объектов, при запуске на обновлённой СУБД существенно выше.
Как пример типичного запроса. При попытке его прочитать у меня вскипает мозг от частоты пререключения языка.
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
БД мессенджера (ч.1): проектируем каркас базы