Використання російських назв в тексті SQL-запиту.
Прошу допомоги майстрів.
Можливо завдання має краще рішення, крім того,
хотів би дізнатися коректність свого варіанту.
Є ряд запитів, наприклад (привожу укорочений варіант):
SELECT
# XA0; Subject.Familiya as [Прізвище],
# XA0; Location.Tip as [Тип країни]
FROM
# XA0; Subject, Location
WHERE
# XA0; Subject.S_L_id = Location.L_id
Виходить російські назви полів зберігаються в самих же запитах
як псевдоніми.
Всі ці запити використовуються самі по собі, але крім того
кожен з них використовується і як вкладені запити, наприклад:
select a. [Тип країни], count (*) as [Кількість]
from (
# XA0; SELECT
# XA0; # XA0; Subject.Familiya as [Прізвище],
# XA0; # XA0; Location.Tip as [Тип країни]
# XA0; FROM
# XA0; # XA0; Subject, Location
# XA0; WHERE
# XA0; # XA0; Subject.S_L_id = Location.L_id
) a
group by # XA0; a. [Тип країни]
Що мені в цьому не подобається, так це те, що в тексті запиту використовується
російський псевдонім a. [Тип країни].
Це, як мені здається, не зовсім красиво.
Чи не виникнуть проблеми з цим на інших PC?
З іншого боку, тримати масив рядків з мітками полів тільки заради цього
незручно. Тримати 2 списку запитів, де кожна пара на 95% повторюється
теж незручно.
От якби можна було б ставити кілька псевдонімів полю або звертатись до нього
по його початкового назвою.
Так от питання: чи коректно використовувати російські назви в тексті SQL-запиту?
СУБД Access, ADO.
коректно використовувати російські назви в тексті SQL-запиту
Все залежить від СУБД. Якщо СУБД підтримує Юнікод або російські кодування, то цілком коректно.
> Коректно використовувати російські назви в тексті SQL-
> Запиту?
Ні.
Мені здається, що для Access це нормально.
я не використовую. Краще вже давати російська назва в дескрипторі поля (displaylabel). запити коротше і зрозуміліше виходять.
> SELECT
> # XA0; Subject.Familiya as [Прізвище],
> # XA0; Location.Tip as [Тип країни]
> FROM
> # XA0; Subject, Location
> WHERE
> # XA0; 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
Значить російські назви зберігати поза SQL?
> Російські назви використовувати тільки в інтерфейсі програми.
> І ніде більше!
Понімяу.
Значить використовувати додатково масив для зберігання назв полів?
> Хіба не краще?
> SELECT s.Familiya, l.Tip
> FROM Subject s
> IHHER JOIN Location l ON s.S_L_id = l.L_id
Згоден, краще, ніяк перевчитися не можу, звичка.
> Я не використовую. Краще вже давати російська назва в дескрипторі
> Поля (displaylabel).
Так не вийде в цьому завданні,
тому один і той же набір даних буде обробляти різні запити, тобто
дизайн-тайм створювати TField неможливо, та й ран-тайм теж напевно змила немає?
А вже потім, прочитавши дані файлу, звичайно привласнювати displaylabel значення масиву.
> Ага, зрозумів. А про проперти Fields у TDataSet ти не чув?
:)) чув
> Так. Да наверно. Так, але дуже стрьомно. Так, "але вже краще
> Ви до нас ":)
> Вже скільки було гемороїв з російською мовою в Дельфи!
Краще вчасно внести зміни при проектуванні, ніж потім
перелопачувати справно працює код.
Спасибі, почну з ранку переробляти (благо, поки небагато).
> До речі. Чи знає хто якусь мову, у якого буква потрапила
> Б на код 255?
Не знаю а що? Код як код ..
>> До речі. Чи знає хто якусь мову, у якого буква потрапила
>> б на код 255?
>
> Не знаю а що? Код як код ..
>
Для деяких версій Дельфі, наявність такого коду в тексті програми - це "червона ганчірка"! Точніше на початку тексту програми. Ще точніше - не пам'ятаю. (Склероз, блін.
> Та й ран-тайм теж напевно змила немає?
звичайно, ні. вони самі створюються. якщо вже хочеться в рантайм російські назви призначати роби це в afteropen (коли вони вже створилися) і все.
Хлопці, ви, напевно, файли все також продовжуєте називати в форматі 8.3? Так?
>> коректно використовувати російські назви в тексті SQL-
>> запиту?
Не все так однозначно. Наведу навскидку 2 ситуації
1) У мене так напевно майже у кожного накопичена колекція запитів - "утиліт" скажімо статистика сесії, динаміка введення-виведення і інші дані із системних таблиць. Виконую я їх з SQL * Plus і іноді результат потрібно кому-небудь послати. Форматнуть висновок в HTML це одна команда і 0.1 сек. часу. Перейменовувати поля (а часто і результати усіляких обробок) це вже довго а доведеться робити постійно. Тому все результати заздалегідь з російськими псенвдонімамі
2) Безліч поточних звітів загорнуті як збережені процедури повертають курсор. Користуються ними клієнтські програми двох десятків типів - і веб-сервіси (в тому числі чужі) і товсті клієнти і тонкі HTML клієнти і ще фіг знає хто. Писати в усіх них перетворення заголовків (і міняти потім) - зайві проблеми. Точно такде курсор йде з російськими заголовками полів. Працює як годинник. # XA0; Альтернативні шляхи вирішення мені відомі, але цей спосіб цілком працездатний і має право на життя навіть не ІМХО
> Чи знає хто якусь мову, у якого буква потрапила б на код 255?
Часто-густо. Відкрий таблицю символів в Віндоус і подивися.
> Sergey Masloff (06.05.07 10:45) [19]
Це все виправдано. Але виправдано тільки ресурсоємних перероблення. Тому, що спочатку було продумано. Були смішити базові точки проектування - зберігання (спосіб зберігання в частині імен) і відображення.
І я не кажу, що даний спосіб нежиттєздатний або непрацездатний. В окремих приватних випадках.
Я говорю ТІЛЬКИ про те, що національні символи в SQL в якості конструкцій мови, як лексем і т.д. і т.п. є некоректним.
Так. скільки людина стільки й думок.
зовсім з пантелику збили.
Все, виправив.
Всім дякую.