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

Вниз

Запрос с параметром   Найти похожие ветки 

 
Астроном   (2004-08-31 08:24) [0]

Например есть таблица, к примеру, клиентов...
поля в ней такие: Код, Имя, Адрес, Телефон

Хочу сделать поиск по таблице... Создаю форму, кидаю четыре Edit"а, которые обзначают соответственно Код, Имя, Адрес, Телефон...
Создаю запрос:
SELECT * FROM clients
WHERE code=:scode, name=:sname, adress=:sadress, phone=:sphone

Это если поиск идет по четырем полям... А если я хочу с помощью этой формы найти клиента только по названию? Заполняю один Edit, другие оставляю пустыми... А запрос? Создавать такой:
SELECT * FROM clients WHERE name=:sname
Или можно как-то "спрятать" параметры scode,sadress,sphone в первом запросе?

С уважением...


 
Наталия ©   (2004-08-31 08:43) [1]

SELECT * FROM clients
WHERE (code = :scode or :scode is null)
and (name=:sname or :name is null)
and ...


 
Наталия ©   (2004-08-31 08:44) [2]

Или динамически запрос формируй...


 
KSergey ©   (2004-08-31 08:52) [3]

> [2] Наталия ©   (31.08.04 08:44)
> Или динамически запрос формируй...

Это намного лучше, т.к. иначе план выполнения - просто безобразный.


 
KSergey ©   (2004-08-31 08:52) [4]

Иначе- в смысле как в [1]


 
Rule ©   (2004-08-31 08:56) [5]

Просто присвой нулевые значения параметрам, тоесть типа такого
Querry.params[0].asstring:=""; и все


 
Астроном   (2004-08-31 13:10) [6]


> KSergey ©   (31.08.04 08:52) [3]
> > [2] Наталия ©   (31.08.04 08:44)
> > Или динамически запрос формируй...
>
> Это намного лучше, т.к. иначе план выполнения - просто безобразный.

А если записей в таблице около 20?


> Rule ©   (31.08.04 08:56) [5]
> Просто присвой нулевые значения параметрам, тоесть типа
> такого
> Querry.params[0].asstring:=""; и все

А не будет ли производиться поиск по пустым значениям?


 
KSergey ©   (2004-08-31 13:12) [7]

> [6] Астроном   (31.08.04 13:10)
> А если записей в таблице около 20?

Тогда до лампочки.


 
Rule ©   (2004-08-31 14:13) [8]

А не будет ли производиться поиск по пустым значениям?

тфу перепутал с Like,  я бы посоветовал бы сделать запрос вот так:
SELECT * FROM clients
WHERE code like :scode and name like :sname and adress like :sadress and phone like :sphone

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


 
Астроном   (2004-08-31 14:24) [9]


> KSergey ©   (31.08.04 13:12) [7]
> > [6] Астроном   (31.08.04 13:10)
> > А если записей в таблице около 20?
>
> Тогда до лампочки.

В смысле?


 
KSergey ©   (2004-08-31 14:31) [10]

> [9] Астроном   (31.08.04 14:24)
> > Тогда до лампочки.
> В смысле?

Ну на таком кол-ве записей один фиг какой запрос: оптимальный или нет.


 
Val ©   (2004-08-31 15:04) [11]

На мой взгляд - лучшее решение в подобном случае - динамическое формирование запроса. Даже если в данной задаче у вас 20 записей, это не означает, что их всегда будет столько. А хороший тон останется :)


 
Астроном   (2004-08-31 18:52) [12]

Извиняйте, оговорился: не 20 записей, а 20 полей...


 
Rule ©   (2004-09-01 08:40) [13]

Val ©   (31.08.04 15:04) [11]
А в чем плохой тон параметров ?


 
_sulent ©   (2004-09-01 09:46) [14]

Плохой, не плохой... кто как привык, и кому как удобно, мне так кажется!
По мне лучше динамически, сам контролируешь и сам фильтуешь то, что нужно!


 
KSergey ©   (2004-09-01 10:00) [15]

> [14] _sulent ©   (01.09.04 09:46)

Не совсем кто как привык.
Это, правда, не к этой ветке, другая была. Но тут скажу, раз попалось: если кол-во условий в WHERE меняется в зависимости от ввода пользовтеля - тогда удобнее динамически запрос сформировать. Т.к. динамически менять состав параметров - мама дорогая... Еще и типы им выставлять и т.д.
А вот если состав параметров постоянный - тогда параметры - хорошо. Правда, опять проблемка: это хорошо, когда все на этапе разработки можно в квери покласть. А если один квери да для разного используется? Опять динамическое формирование состава параметров?? Нет уж, дешевле запрос в виде текста сформировать.


 
Val ©   (2004-09-01 10:18) [16]

>[13] Rule ©   (01.09.04 08:40)
покажите где я это говорил, пожалуйста.


 
_sulent ©   (2004-09-01 10:58) [17]

Я привык чтобы динамически все формировалось, для меня удобнее и приятнее смотрится, не надо кучу кверей пускать в них черт ногу сломит... а кому нравятся параметры, то для них проблемой не будет написать := nil; и все...
Но динамический на мой взгляд более обоснованней...
Да еще есть один неприятный прикол, когда через АДО подрубаешься к MS SQL, то возникают проблемы с датой...


 
Sergey13 ©   (2004-09-01 11:03) [18]

ИМХО.
В данном конкретном случае, при любых произвольных параметрах поиска, проще наверное динамически формировать запрос (или условие фильтра). Но обычно предпочтительнее параметры - сервера их любят больше.


 
Val ©   (2004-09-01 11:06) [19]

Почему пытаетесь обязательно разделить понятие динамического формирования и параметров? Как пример:

Q.SQL.Add("select * from mytable where 1=1 ");
case MyFlag of
 0:begin
      Q.SQL.Add(" and field1 = :p1");
      Q.ParamByName("p1").AsString := Edit1.Text;
    end;
 1:begin
       Q.SQL.Add("and field2 = :p2" ");
       Q.ParamByName("p2").AsDateTime := Now;
    end;
end;


 
Sergey13 ©   (2004-09-01 11:12) [20]

2[19] Val ©   (01.09.04 11:06)
>Почему пытаетесь обязательно разделить понятие динамического формирования и параметров?
Потому что при динамическом формировании параметры (если применяются) не выполняют своей первоначальной роли - исключения разбора запроса на сервере. Да, они помогают избежать несоответствия типов и т.п., но... см выше.


 
Val ©   (2004-09-01 11:23) [21]

>[20] Sergey13 ©   (01.09.04 11:12)
это почему же? поясните.


 
Sergey13 ©   (2004-09-01 11:24) [22]

2[21] Val ©   (01.09.04 11:23)
>это почему же? поясните.
Что конкретно?


 
Val ©   (2004-09-01 11:28) [23]

Фразу о динамическом формировании запроса и не выполнении первоначальной роли параметров, по вашему.


 
Val ©   (2004-09-01 11:35) [24]

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


 
Sergey13 ©   (2004-09-01 11:37) [25]

А что тут непонятного? Зачем параметры нужны по твоему? По моему, что бы исключить разбор запроса сервером. Если в памяти сервера хранится нечто вроде select * from table where id=:id то при повторном таком же запросе он не будет его разбирать, а если ему попадется select * from table where id=:id and pole=:pole и он не найдет его в памяти будет разбор. Иногда время разбора сопоставимо с временем исполнения.

ЗЫ: разумеется все это для "взрослых" серверов а не для ЛОКАЛ СКЛ.


 
KSergey ©   (2004-09-01 14:33) [26]

> [19] Val ©   (01.09.04 11:06)
>        Q.SQL.Add("and field2 = :p2" ");
>        Q.ParamByName("p2").AsDateTime := Now;

Не факт, что гладко это пройдет. Возможно - пошаманить придется.
Еще в защиту динамических зпросов (без параметров) - их отладить легче. Взял полученный текст - и смотришь. С параметрами - не так все прозрачно


 
Rule ©   (2004-09-01 15:42) [27]

2Val ©   (01.09.04 10:18) [16]

Val ©   (31.08.04 15:04) [11][Ответить]
На мой взгляд - лучшее решение в подобном случае - динамическое формирование запроса. Даже если в данной задаче у вас 20 записей, это не означает, что их всегда будет столько. А хороший тон останется :)


 
Val ©   (2004-09-01 15:43) [28]

>[27] Rule ©   (01.09.04 15:42)
и..?


 
Rule ©   (2004-09-01 15:47) [29]

KSergey ©   (01.09.04 14:33) [26]С параметрами - не так все прозрачно

НУ не знаю гед как а в интербезе есть SQLMonitor, который все и показывает особых поблемм с параметрами не возникает, и в защиту параметров, происходит автоматическая конвертация форматов дат и разделителей, чего надо боятся при полном динамическом формировании запроса


 
Rule ©   (2004-09-01 17:20) [30]

Val ©   (01.09.04 15:43) [28]

Val ©   (31.08.04 15:04) [11]
На мой взгляд - лучшее решение в подобном случае - динамическое формирование запроса. Даже если в данной задаче у вас 20 записей, это не означает, что их всегда будет столько. А хороший тон останется :)


 
Rule ©   (2004-09-01 17:21) [31]

продолжение Rule ©   (01.09.04 17:20) [30]
тоесть получается что типа хорошего тона в запросах нет :), ну это уже просто так придирание к словам, если я не так понял, то извините, думаю из этого димагогию разводить не стоит :)


 
Sergey13 ©   (2004-09-01 17:28) [32]

2[31] Rule ©   (01.09.04 17:21)
>тоесть получается что типа хорошего тона в запросах нет :),
Естественно нет. Ты видел когда нибудь, что бы воспитанные люди на SQL разговаривали? 8-)


 
Val ©   (2004-09-01 17:34) [33]

>[30] Rule ©   (01.09.04 17:20)
Фразой, которую вы выделили, я говорил автору, что делать надо правильно с самого начала, чтобы не было печально потом. И неважно 20 у него записей или 200000, это относилось к высказываниям типа "пофиг". На 20-ти, действительно, пофиг, но привыкать что всегда будет пофиг не стОит.


 
Rule ©   (2004-09-01 17:46) [34]

Sergey13 ©   (01.09.04 17:28) [32]
Не поверишь, видел :)))

Val ©   (01.09.04 17:34) [33]
Полностью согласен и солидарен :)


 
Sergey13 ©   (2004-09-01 17:53) [35]

2[34] Rule ©   (01.09.04 17:46)
>Не поверишь, видел :)))
Между собой разговаривали? Тогда они может и воспитанные, но не в себе были. 8-)



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

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

Наверх




Память: 0.56 MB
Время: 0.024 c
6-1090969315
Dmitry
2004-07-28 03:01
2004.10.03
Indy SMTP


14-1095319296
BiN
2004-09-16 11:21
2004.10.03
Смех да и только (ну цинник я, цинник)


3-1094454200
ksa2002
2004-09-06 11:03
2004.10.03
Количество возвращаемых записей


14-1094975356
Stef
2004-09-12 11:49
2004.10.03
Фракталы


4-1093116755
dRake
2004-08-21 23:32
2004.10.03
Редактор ресурсов