Осторожно! Больная тема и особорелигиозная. Но хотелось бы таки понять, насколько это былоподход и главное - почему? Я понимаю, что сейчас полетят тухлые помидоры. Но какие у вас аргументы против? И есть ли кто-то с аргументами ЗА? Стоит сразу подчеркнуть, что речь только о продуктах для внутреннего рынка. Понятное дело, что если вы разрабатываете продукт для буржуев, то это отдельная тема.

Неудобно переключаться между языками и все такое прочее при написании кода - это уже классика. Что-нибудь еще?

Задавать имена таблиц и столбцов на транслите считается верхом неприличия. Типа надо на инглише. Окей, но разве когда имена таблиц заданы с помощью гуглтранслейта это лучше? Да, может быть не все этим страдают, но я видел много коммерческих продуктов, в которых имена заданы на английском, но сразу видно, что это было сделано без учета контекста, то есть с помощью гуглтранслейта или, когда речь идет о самых простых словах, то с помощью собственного словарного запаса уровня третьего класса начальной школы, без какого-либо учета правил английского. Ну, например, когда хотят перевести "тип класса" пишут TypeClass, вместо ClassType или "тип операции" переводят как TypeOperation. То есть имеет место прямой дословный перевод с русского (конечно, в каких-то случаях такой подход, когда слово Type впереди, мог быть выбран ради сортировки столбцов или таблиц в списке, чтоб все типы рядышком были). Недавно была задача интеграции с одним известным программным комплексом, уровня Enterprise, который используется в очень многих крупных эээ..., ну в общем... не важно где. Там было таких ошибок просто одна на другой. И у меня всегда возникает вопрос в таких ситуациях: друзья, господа, коллеги, зачем вы пишите названия на английском, применяя свой словарный запас уровня третьего класса "лондон из зЭ кЭпитал..." ну вы поняли, - зачем? Думаете, это круче, чем TipClassa? Когда носитель будет читать это гэ... он будет испытывать боль и не только носитель, но и тот, кто знает инглиш чуть лучше уровня третьего класса. Он будет писать Select OperationType from ..., а система ему скажет - нене, дружище, нет такого столбца! Получается, что такой кривой английский только усложняет жизнь.

Что гласит закон джунглей? Закон джунглей гласит, что код должен быть понятным, не так ли? Часто даже жертвуют производительностью, ради понятности (разумеется, там, где это не критично), о компактности уже и речи не идет. Все эти табуляции, разрывы и прочее были придуманы точно не ради экономии места на экране, а вызов процедуры и возврат занимает несколько дополнительных тактов процессора, но сейчас это уже никого не волнует.

Когда речь идет о языках программирования, там львиную долю занимают операторы, переменные, встроенные процедуры и функции, которые на английском. И хотя сейчас всё в юникоде и некоторые языки позволяют создавать имена переменных на русском, это бред.

Но когда речь идет о базе данных, то в запросах 90% это имена таблиц и столбцов и оставшиеся 10% это ключевые слова.
insert, update, select... зачем перечислять, вы и так знаете. Соединение, снова условия по именам таблиц и столбцам, сортировки, группировки, оконки, pivot и unpivot и так далее. Открыл квадратную скобку и интеллисенс нам поможет избавиться от лишних переключений. Но даже на чистом инглише вам придется иногд переключиться, чтобы написать комент или текст сообщения об ошибке. Или, скажете, у вас коменты тоже на англицком?

То есть в запросах мы работаем в основном с именами, а не с ключевыми словами, поэтому, когда столбцы названы на русском, уровень понятности зашкаливает. Когда это огромная портянка, а не просто
, то сплошные плюсы, чем когда, уж простите, какой-нибудь горе-переводчик поназывал таблицы и алиасы так, что по имени не сразу поймешь, что он хотел сказать, пока не просмотришь всю логику заполнения этой таблицы, зато БМВ типа на английском, совесть перед сообществом чиста, я не быдлокодер, можно спать спокойно!

P.S. я не случайно создал топик именно в этом разделе, потому что речь конкретно о сиквеле, так что не нужно про другие СУБД и возможные в них проблемы.

Ага. Догадайтесь с трёх раз, что выводит запрос




судя по всему, вы точно знаете, что выводит запрос?




В базе ~3000 таблиц. Примерно столько же процедур/функций/вьюх. При открывании [ интеллисенс при таких вводных подвешивает студию на ощутимое время. А после этого без переключения клавиатуры останется всего-то промотать список из 3000 пунктов стрелочкой вниз до нужного.


когда в базе over3000 таблиц, то английские имена не спасут тоже и интеллисенс зависнет с таким же успехом и даже без квадратных скобок, а как только вы поставите точку после dbo иии? поэтому на русском писать не надо?

как это отосится к теме?

env,
хороший аргумент про jdbc

felix_ff,
легко сказать - отправить разрабов на курсы
искать сразу с достойным знанием, мы повышаем порог вхождения
наслаивается куча проблем

Но не будем зацикливаться только на СУБД

возьмем, к примеру, SSAS и Visual Studio
он создает модель с локалью RU
Следовательно, имена таблиц там физически называются на русском. Если их назвать на инглише, то нужно транслейт прикрутить, но русский транслейт стандартными средствами не прикручивается к локали RU
Написание DAX запросов подразумевает всё то, что вы выделили красным, бесит, соглашусь, но что делать? Так микрасофт организовал работу своих продуктов.

Выход: создавать модель с локалью EN, добавлять транслейт, дальше поддерживать имена таблиц и транслейтов, иначе пользователь в PowerBI или Excel увидит английские имена и будет округлять глаза. В результате поддержка этих костылей оказывается дороже нескольких дополнительных переключений, разве нет?

TJ001 Когда это огромная портянка, а не просто
select * from t1
Так было сказано

Но тут вопрос как раз в плоскости не отдельно взятого разработчика, а команды, когда мнения расходятся. Вот и хочется узнать мнения по этому поводу. Аргументы тех, кто за, я изложил и тех, кто против тоже и проблемы команды в общем-то тоже, когда не у каждого достаточный уровень знания английского. Приходится либо согласовывать имена столбцов, либо имеем в конце кто в лес, кто по дрова. То Sales то Purchase, когда речь и там и там о продажах.

В том-то и проблема, что вроде как одно и тоже, но названо по-разному, а это уже не хорошо, потому что в рамках одной системы такого быть не должно или так или так. Но приходит новый человек и у него даже мыслей не возникает спросить, он же точно знает, что продажи - это Sales, так и пишет, а другой днем раньше уже назвал Parchase. Понятное дело, что все это исправляется и договоренность какая-то будет достигнута, но это время и нервы, а потом еще и ошибки, вызванные пакетным переименованием через Ctrl+H, которые несопоставимы с лишними двумя десятками или даже сотнями переключений раскладки. Можно сказать что это все плохое управление, но это же люди, они всегда преподносят сюрпризы. Когда самолет летает из точки А в точку Б уже несколько лет каждый день, там все движения механические и отточены, а разработка такое дело...


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

Нет, с ним проблем, как таковых, нет
Проблема, когда начинаешь это склеивать, когда запрос идет одновременно к кубу на русском, к БД на английском и прочее.

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

А там еще MDS подключается, который тоже как бы... Псевдонимы можно таблицам давать на русском, а реальные имена на английском, но потом ты такой хочешь вынуть оттуда [Должность сотрудника], вот она, в экселе, я ее вижу... Но как она называется в реальности? Отлично, идем в модель, ищем долбаную таблицу, открываем, смотрим АГА! Вот оно! Написал в запросе. Теперь мне нужен адрес из другой модели, вот он, я его вижу в браузере, но как реально называется таблица и столбец? GoTo 1.

Кого бы еще застрелить?

Что касается всяkих сочеtаний символов в одном слове, типа "ABC анализ" тут только одно правило - писать в другом регистре, использовать CamelCase и не в середине слова. А что еще делать, когда зоопарк?

env,

Не пробовал :D

выделенная буква - на кириллице :)

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

felix_ff,

мой вопрос к 1с не имеет отношения))
а лишь является следствием необходимости соединять куб, DWH и MDS
если бы в MDS были русские названия столбцов и таблиц, не пришлось бы делать те итерации, о которых я написал - ходить и смотреть оригинальное название таблицы, всё было бы на русском

но дело не только в русском, но и в кривых переводах, что почти одно из той же оперы что и транслит
почему тогда не транслит?

синтаксическая проверка (не запроса, а слов) иногда помогает, но далеко не всегда и не везде она есть