Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

SQL [D5, D6, D7, IB6.x]

Страницы: 1 2 >
Lika © (2004-04-12 11:42:00)
Уважаемые мастера, подскажите пожалуйста
как можно заменить условие SQL запроса:
Where (имя_поля LIKE "символьная строка %")OR(имя_поля LIKE "другая символьная строка %")OR(имя_поля LIKE "другая символьная строка %")и т.д (очень длинное условие)
на более оптимальное условие?
Я хотела бы что-то вроде этого:
Where имя_поля IN ("символьная строка", "другая символьная строка",...), но как сделать чтобы сравнение было типа LIKE т.е значение поле начиналось с этих символов, а не полностью совпадало с ними.
Помогите пожалуйста, очень замучалась с таким длинными условиями!
Заранее всем спасибо!

Lika (2004-04-12 16:41:00) [1]

> В том числе не следует забывать, что кроме LIKE есть "...
> where substr(FIELD1, i, j) = :STRING1"

Большое спасибо!!! Это то что мне нужно, а почему-то об этом не подумала! Еще раз спасибо!

serge35 (2004-04-12 16:41:00) [2]
Это для одного уровня иерархии. А дальше?
Глубина вложенности по условию не ограничена.

Курдль (2004-04-12 15:54:00) [3]

> Простите, а как динамически определять длину символьной
> строки и позицию начала сравнения?

Это ко мне вопрос? Речь идет о сравнении бухгалтерских счетов типа "51_01_05", например, с целью выделить все субсчета этого счета типа "51_*".
В данном случае оперировать позициями и длинами удобнее.

serge35 (2004-04-12 15:50:00) [4]
Простите, а как динамически определять длину символьной строки и позицию начала сравнения?

Курдль (2004-04-12 15:48:00) [5]
В том числе не следует забывать, что кроме LIKE есть "... where substr(FIELD1, i, j) = :STRING1"

serge35 (2004-04-12 15:47:00) [6]
К сожалению разработчики SQL не предусмотрели варианта для работы с планом счетов предприятия...

Lika (2004-04-12 15:46:00) [7]

> "универсальный составитель запросов" (это уже прикол)...

Это идея! Вот с этим запросом разберусь и начну :))(шутка)

> Напишите процедуру на серваке (это в идеале), кусок кода
> на клиенте (что тоже не плохо)

Процедур на серваке полно!:) Но эту проблему они не решают.
Мне нужно просто знать как сравнить значения поля с множеством символьного типа,но не точно,а "приблизительно".
Если кто знает подскажите пожалуйста, плиз.

Курдль (2004-04-12 15:22:00) [8]

> А меня интересует в принципе, как можно организовать такого
> рода запрос.

А чего Вы так прикипели к запросам? Напишите процедуру на серваке (это в идеале), кусок кода на клиенте (что тоже не плохо), "универсальный составитель запросов" (это уже прикол)...

Lika (2004-04-12 15:19:00) [9]

> Тогда перепроектируйте БД, как я Вам и советовал!

:)) А без этого никак нельзя :), потому что это тема уже отдельного разговора.
А меня интересует в принципе, как можно организовать такого рода запрос. Или это невозможно, неужели в SQL нет варианта на такой случай. :(

Курдль (2004-04-12 14:57:00) [10]

> План счетов предприятия.

И что, он у Вас не иерархический (древовидный)?
Тогда перепроектируйте БД, как я Вам и советовал!
Извлекать субсчета из их кода - методически неверно!

Lika (2004-04-12 14:55:00) [11]

> А план счетов банковский или "организаций и предприятий"?

План счетов предприятия.

Lika (2004-04-12 14:54:00) [12]

> а если нет... то чего сложного непонимаю... автоматизировать
> создание запроса с like сложно или что?

Счета известны, а вот субсчета нет. В этом и вся загвоздка.

> а если нет... то чего сложного непонимаю... автоматизировать
> создание запроса с like сложно или что?

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

Курдль (2004-04-12 14:50:00) [13]
А план счетов банковский или "организаций и предприятий"?

Lika (2004-04-12 14:48:00) [14]

> А что делают OR? и как организовано хранение счетов в базе?

Все счета хранятся в таблице "план счетов"

> Не мучайте сервер такими запросами, или перепроектируйте
> базу!
> Обычно такие проблемы решаются на клиенте, а не на сервере,
> элементарной фильтрацией набора данных.
> А чаще всего даже более-менее навороченные "гриды" имеют
> встроенный механизм фильтрации.

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

Курдль (2004-04-12 14:32:00) [15]
Не мучайте сервер такими запросами, или перепроектируйте базу!
Обычно такие проблемы решаются на клиенте, а не на сервере, элементарной фильтрацией набора данных.
А чаще всего даже более-менее навороченные "гриды" имеют встроенный механизм фильтрации.

serge35 (2004-04-12 14:22:00) [16]
А что делают OR? и как организовано хранение счетов в базе?

roottim (2004-04-12 14:20:00) [17]
>нужные счета
если они известны точно, то пожайлуста...

а если нет... то чего сложного непонимаю... автоматизировать создание запроса с like сложно или что?

Lika (2004-04-12 14:07:00) [18]
А что мне даст UNION, у меня и запрос с OR работает.
Мне просто хотелось в идеале, чтобы я вообще в спике переменных могла объявить нужные счета как множество.
А затем в запросах ссылаться на это множество.
А список субсчетов пользователи могут сами менять поэтому я не хочу их "жестко" задавать.
Не ужели нет никаких вариантов?

serge35 (2004-04-12 13:56:00) [19]
Значит надо сделать 10 или лучше 20 UNION, чтобы наверняка.

Lika (2004-04-12 13:52:00) [20]

> Если уровень вложенности ограничен, например 5 субсчетами,
> то надо делать UNION для каждого уровня субсчетов.

Нет он не ограничен у одних счетов может быть 2субсчета, у других 10

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »