Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2007.05.27;
Скачать: CL | DM;

Вниз

Использование русских названий в тексте SQL-запроса.   Найти похожие ветки 

 
Kostafey ©   (2007-05-05 21:08) [0]

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

Имеется ряд запросов, например (привожу укороченный вариант):

SELECT
 Subject.Familiya as [Фамилия],
 Location.Tip as [Тип страны]
FROM
 Subject, Location
WHERE
 Subject.S_L_id = Location.L_id

Получается русские названия полей хранятся в самих же запросах
как псевдонимы.

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


select a.[Тип страны], count(*) as [Количество]
from (
 SELECT
   Subject.Familiya as [Фамилия],
   Location.Tip as [Тип страны]
 FROM
   Subject, Location
 WHERE
   Subject.S_L_id = Location.L_id
) a
group by  a.[Тип страны]


Что мне в этом не нравится, так это то, что в тексте запроса используется
русский псевдоним a.[Тип страны].
Это, как мне кажется, не совсем красиво.
Не возникнут ли проблемы с этим на других PC ?

С другой стороны, держать массив строк с метками полей только ради этого
неудобно. Держать 2 списка запросов, где каждая пара на 95% повторяется
тоже неудобно.

Вот если бы можно было бы задавать несколько псевдонимов полю или обращатся к нему
по его первоначальному названию.

Так вот вопрос: корректно ли использовать русские названия в тексте SQL-запроса?
СУБД Access, ADO.


 
Зюзя   (2007-05-05 21:25) [1]

корректно ли использовать русские названия в тексте SQL-запроса

Все зависит от СУБД. Если СУБД поддерживает Юникод или русские кодировки, то вполне корректно.


 
Johnmen ©   (2007-05-06 00:22) [2]


> корректно ли использовать русские названия в тексте SQL-
> запроса?

Нет.


 
McSimm ©   (2007-05-06 00:41) [3]

Мне кажется, что для Access это нормально.


 
sniknik ©   (2007-05-06 01:27) [4]

я не использую. предпочитаю давать русское название в дескрипторе поля (displaylabel). запросы короче и понятнее получаются...

> SELECT
>   Subject.Familiya as [Фамилия],
>   Location.Tip as [Тип страны]
> FROM
>   Subject, Location
> WHERE
>   Subject.S_L_id = Location.L_id

разве не лучше?
SELECT s.Familiya, l.Tip
FROM Subject s
IHHER JOIN Location l ON s.S_L_id = l.L_id


 
Германн ©   (2007-05-06 01:49) [5]


> sniknik ©   (06.05.07 01:27) [4]
>
> я не использую. предпочитаю давать русское название в дескрипторе
> поля (displaylabel). запросы короче и понятнее получаются.
> ..

Поддерживаю. Русские названия - только в визуальных компонентах. Во "внутренностях!" только родные. И не только в SQL. Вон немцы, имхо, названия функций и переменных дают порой на немецком. Так ведь прочитать не возможно! :)


 
Kostafey ©   (2007-05-06 02:04) [6]

Значит русские названия хранить вне SQL ?


 
Германн ©   (2007-05-06 02:06) [7]


> Kostafey ©   (06.05.07 02:04) [6]
>
> Значит русские названия хранить вне SQL ?
>

Русские названия использовать только в интерфейсе программы. И нигде более!


 
Kostafey ©   (2007-05-06 02:14) [8]

> Русские названия использовать только в интерфейсе программы.
> И нигде более!

Понимяу.
Значит использовать дополнительно массив для хранения названий полей?


> разве не лучше?
> SELECT s.Familiya, l.Tip
> FROM Subject s
> IHHER JOIN Location l ON s.S_L_id = l.L_id

Согласен, лучше, никак переучиться не могу, привычка...


 
Kostafey ©   (2007-05-06 02:19) [9]

> я не использую. предпочитаю давать русское название в дескрипторе
> поля (displaylabel).

Так не получится в этой задаче,
т.к. один и тот же набор данных будет обрабатывать разные запросы, т.е.
дизайн-тайм создавать TField невозможно, да и ран-тайм тоже наверное смыла нет?


 
Германн ©   (2007-05-06 02:20) [10]


> Kostafey ©   (06.05.07 02:14) [8]
>
> > Русские названия использовать только в интерфейсе программы.
>
> > И нигде более!
>
> Понимяу.
> Значит использовать дополнительно массив для хранения названий
> полей?
>

Не понял. Чем тебя не устраивает displaylabel упомянутый в sniknik ©   (06.05.07 01:27) [4]?


 
Германн ©   (2007-05-06 02:25) [11]


> Kostafey ©   (06.05.07 02:19) [9]
>
> > я не использую. предпочитаю давать русское название в
> дескрипторе
> > поля (displaylabel).
>
> Так не получится в этой задаче,
> т.к. один и тот же набор данных будет обрабатывать разные
> запросы, т.е.
> дизайн-тайм создавать TField невозможно, да и ран-тайм тоже
> наверное смыла нет?
>

Ага, понял. А о проперти Fields у TDataSet ты не слышал?


 
Kostafey ©   (2007-05-06 02:25) [12]

> Не понял. Чем тебя не устраивает displaylabel упомянутый
> в sniknik ©   (06.05.07 01:27) [4]?

Запросы хранятся в файлах. Было бы дико (как мне кажется) держать тексты запросов
отдельно от русских названий полей для результатов запросов.
Т.е. нужно и эти данные хранить в том же файле вместе с запросами.

А уж потом, считав данные файла, конечно присваивать displaylabel значения массива.


 
Kostafey ©   (2007-05-06 02:26) [13]

> Ага, понял. А о проперти Fields у TDataSet ты не слышал?

:)) слышал


 
Германн ©   (2007-05-06 02:49) [14]


> Kostafey ©   (06.05.07 02:25) [12]
>
> > Не понял. Чем тебя не устраивает displaylabel упомянутый
> > в sniknik ©   (06.05.07 01:27) [4]?
>
> Запросы хранятся в файлах. Было бы дико (как мне кажется)
> держать тексты запросов
> отдельно от русских названий полей для результатов запросов.
>
>

Да. Да, наверно. Да, но очень стрёмно. Да, "но уж лучше Вы к нам" :)
Уж сколько было геморроев с русским языком в Дельфи!
Кстати. Знает ли кто какой-то язык, у которого буква попала бы на код 255?


 
Kostafey ©   (2007-05-06 02:56) [15]

> Да. Да, наверно. Да, но очень стрёмно. Да, "но уж лучше
> Вы к нам" :)
> Уж сколько было геморроев с русским языком в Дельфи!

Лучше вовремя внести изменения при проектировании, чем потом
перелопачивать исправно работающий код.
Спасибо, начну с утра переделывать (благо, пока немного).

> Кстати. Знает ли кто какой-то язык, у которого буква попала
> бы на код 255?

Не знаю а что? Код как код..


 
Германн ©   (2007-05-06 03:05) [16]


> Kostafey ©   (06.05.07 02:56) [15]
>
> > Да. Да, наверно. Да, но очень стрёмно. Да, "но уж лучше
> > Вы к нам" :)
> > Уж сколько было геморроев с русским языком в Дельфи!
>
> Лучше вовремя внести изменения при проектировании, чем потом
> перелопачивать исправно работающий код.
> Спасибо, начну с утра переделывать (благо, пока немного).
>
>

Правильно сделаешь, имхо.


> > Кстати. Знает ли кто какой-то язык, у которого буква попала
> > бы на код 255?
>
> Не знаю а что? Код как код..
>

Для некоторых версий Дельфи, наличие такого кода в тексте программы - это "красная тряпка"! Точнее в начале текста программы. Ещё точнее - не помню. :( Склероз, блин.


 
sniknik ©   (2007-05-06 03:25) [17]

> да и ран-тайм тоже наверное смыла нет?
конечно нет. они сами создаются... раз уж хочется в рантайм русские названия назначать делай это в afteropen (когда они уже создались) и все.


 
Зюзя   (2007-05-06 08:09) [18]

Ребята, вы, наверное, файлы все также продолжаете именовать в формате 8.3? Да?

P.S. У-у-у, динозавры...


 
Sergey Masloff   (2007-05-06 10:45) [19]

Johnmen ©   (06.05.07 00:22) [2]

>> корректно ли использовать русские названия в тексте SQL-
>> запроса?

>Нет.

Не все так однозначно. Приведу навскидку 2 ситуации
1) У меня да наверное почти у каждого накоплена коллекция запросов - "утилит" скажем статистика сессии, динамика ввода-вывода и другие данные из системных таблиц. Выполняю я их из SQL*Plus и иногда результат нужно кому-нибудь послать. Форматнуть вывод в HTML это одна команда и 0.1 сек. времени. Переименовывать поля (а часто и результаты всяческих обработок) это уже долго а придется делать постоянно. Поэтому все результаты заранее с русскими псенвдонимами

2) Множество текущих отчетов завернуты как хранимые процедуры возвращающие курсор. Пользуются ими клиентские приложения двух десятков типов - и веб-сервисы (в том числе чужие) и толстые клиенты и тонкие HTML клиенты и еще фиг знает кто. Писать во всех них преобразование заголовков (и менять потом) - лишние проблемы. Точно такде курсор идет с русскими заголовками полей. Работает как часы.  Альтернативные пути решения мне известны, но этот способ вполне работоспособен и имеет право на жизнь даже не ИМХО


 
Anatoly Podgoretsky ©   (2007-05-06 13:14) [20]

> Германн  (06.05.2007 02:49:14)  [14]

> Германн © (06.05.2007 02:49) [14]

> Знает ли кто какой-то язык, у которого буква попала бы на код 255?

Сплошь и рядом. Открой таблицу символов в Виндоус и посмотри.

яяяя5мm=ЄняM4яMчэ5 їДуN<Э?


 
Johnmen ©   (2007-05-06 15:38) [21]


> Sergey Masloff   (06.05.07 10:45) [19]

Это всё оправдано. Но оправдано только ресурсоёмкостью переделывания. Потому, что изначально было не продумано. Были смешены базовые точки проектирования - хранение(способ хранения в части имён) и отображение.
И я не говорю, что данный способ нежизнеспособен или неработоспособен. В отдельных частных случаях.
Я говорю ТОЛЬКО о том, что национальные символы в SQL в качестве конструкций языка, в качестве лексем и т.д. и т.п. является НЕКОРРЕКТНЫМ.


 
Kostafey ©   (2007-05-06 15:43) [22]

Да... сколько человек столько и мнений...
совсем с толку сбили...


 
Sergey Masloff   (2007-05-06 15:43) [23]

Johnmen ©   (06.05.07 15:38) [21]
В этом смысле таки да.


 
Kostafey ©   (2007-05-06 17:07) [24]

Все, исправил.
Всем спасибо.



Страницы: 1 вся ветка

Текущий архив: 2007.05.27;
Скачать: CL | DM;

Наверх




Память: 0.54 MB
Время: 0.044 c
15-1177609948
YurikGL
2007-04-26 21:52
2007.05.27
Спам в одной ветке


2-1178525352
delphino
2007-05-07 12:09
2007.05.27
Не могу разобраться с фильтром в delphi


15-1177416368
alex_***
2007-04-24 16:06
2007.05.27
Транзакции для распределенных систем. Кто использовал?


15-1177417383
Невский
2007-04-24 16:23
2007.05.27
проблема при работе с DLL


15-1177875190
ArtemESC
2007-04-29 23:33
2007.05.27
Паскаль-парсер...