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

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

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

Select [D6, MSSQL]

Страницы: 1 2 >
Explorer © (2002-10-11 14:49:00)
Мастера!
к примеру, есть две таблицы : сотрудники и задачи_сотрудников. Таблицы связаные по id_сотрудники.
На форме выбираю из общего списка таблицы_сотрудников, только некоторых (ex. "Иванов, Петров ") и хочу вывести по ним их задачи из таблицы_задачи_сот.
Подскажите, как можно такое реализоватьв запросе к БД?

Explorer (2002-10-15 06:20:00) [1]
Всем большое спасибо!

MMF (2002-10-14 17:00:00) [2]
Johnmen © (14.10.02 16:53)
Да я уже прочитал: имел ввиду генерируемый во время выполнения приложения, динамический запрос. Почему написал параметрический - сам не знаю, наверное Кубань навеяла.

Johnmen (2002-10-14 16:53:00) [3]
>MMF © (14.10.02 16:46)

Послушай, я ж ведь нигде не говорил о параметрах !

MMF (2002-10-14 16:52:00) [4]
MMF © (14.10.02 16:46)
Когда отправил, прочитал - ну конечно, я не имел ввиду "параметрический", ошибочка вышла.

MMF (2002-10-14 16:46:00) [5]
Johnmen © (14.10.02 16:30)
Фактически параметрический запрос со списком будет выполняться медленнее, поскольку запрос с вложенным подзапросом может быть предварительно полностью откомпилирован и оптимизированн сервером, а параметрический потребует разбора парсером.
Да, кстати, ИМХО.

Johnmen (2002-10-14 16:30:00) [6]
>MMF © (14.10.02 16:00)

1. Есть уверенность ? У меня - нет !
2. Даже если это так, то запрос то надо выполнить, а это - время... А так, список уже готов...

MMF (2002-10-14 16:00:00) [7]
Johnmen © (14.10.02 15:48)
1. IN (1,2,3,...) работает во много раз быстрее, чем IN (SELECT ...) - поясни почему: вложенный запрос выполняется один раз, это же не Having.

Johnmen (2002-10-14 15:48:00) [8]
>MMF © (14.10.02 15:36)

Я всего лишь хотел сказать, что
1. IN (1,2,3,...) работает во много раз быстрее, чем IN (SELECT ...)
2. для формирования списка IN надо просто пройтись по букмаркам на отмеченные записи
3. заводить еще поле для признака выборки - абсурд...:)))

MMF (2002-10-14 15:36:00) [9]
Johnmen © (14.10.02 15:23) А что стоит добавить такое поле: 1 символ char(1) * даже на 2000 сотрудников - ерунда, а использовать удобно (скажем разные отчеты по одним и тем же сотрудникам и т.п.).

Max Zyuzin (2002-10-14 15:31:00) [10]
>PSERG (14.10.02 15:01)
Извиняюсь, ваш запрос нашел.
Но не понятно почему он должен рабоать быстрее...

MMF (2002-10-14 15:28:00) [11]
PSERG (14.10.02 15:01) А чем лучше a.фамилия = "Иванов" or a.фамилия = "Петров" и т.д. Эта та же конструкция OR в которую сервер откомпилирует IN

Johnmen (2002-10-14 15:23:00) [12]
>MMF © (14.10.02 15:16)
> "На форме выбираю из общего списка таблицы_сотрудников" т.е.
>Sotr.Selected="Y" (или как ему нравится обозначать выбранных в
>запрос сотрудников)

"Выбранные" в гриде записи это вовсе не значит, что у них есть поле Selected="Y" !!!

passm (2002-10-14 15:20:00) [13]
PSERG (14.10.02 15:01)> Ну, насчет тормозов из-за операции IN - ты, ИМХО, погорячился. Хотя, работаю с DB2, и ручаться за MSSQL не могу, практика показывает что предикат IN нисколько не тормозит запрос. Впрочем, единственное замедление - при смене списка запрос не будет взят из кэша и СУБД вынуждена построить/откомпилировать его заново, но это уже работа СУБД а не БД.
А не хочешь бегать по набору данных - не бегай. Воспользуйся TDBGrid.SelectedRows. Или построй двойной список и дай возможность пользователю "набросать" нужные записи.

MMF (2002-10-14 15:16:00) [14]
помните, в условии вопроса - "На форме выбираю из общего списка таблицы_сотрудников" т.е. Sotr.Selected="Y" (или как ему нравится обозначать выбранных в запрос сотрудников)
select * from Sotr_Zad /*(в смысле не зад, а задача)*/
where Sotr_Zad.Id in (select id from Sotr where Selected="Y")

Max Zyuzin (2002-10-14 15:07:00) [15]
>PSERG (14.10.02 15:01)
Пальцем пожалуйста ткните... а то я вашего запроса не наблюдаю...
И почему должно все это тормозить... объясните пожалуйста..

PSERG (2002-10-14 15:01:00) [16]
Я все-же не понял. О чем вы разговор ведете. Это же тривиальный SQL запрос. То что вы предлагаете будет безбожно тормозить.
Мало того что использование IN в запросе не рекомендовано из-за тормозов, вы еще и советуете на уровне приложения бегать по набору данных и формировать строчку. ПОЛНАЯ ЧУШЬ!!!
Запос я написал несколько сообщений выше.

Max Zyuzin (2002-10-14 14:13:00) [17]
Ну... примерно так..

tmpstr := "where id_сотрудники in (";
Query1.First;
while not Query1.eof do
begin
if (надо добавитьь в список) then
tmpstr := tmpstr + Query1.FieldByName("id_сотрудники").AsString + ",";
Query1.Next;
end;
// В общем в цикле добавляем строку id_сотрудники...
tmpstr := tmpstr + ")";
Ну и потом
Query2.Sql.Add("select * from задачи_сотрудников");
Query2.Sql.Add(tmpstr);
Ну примерно так...

passm (2002-10-14 14:11:00) [18]
Explorer © (14.10.02 13:58)> Посмотри RxQuery - там есть макросы. Пишешь:
SELECT ID, NAME
FROM TABLE1
WHERE ID IN ( %ID_LIST )
И перед открытием формируешь строку:
MacroByName("ID_LIST").AsString = "1,2,5,10"

Hawk2 (2002-10-14 14:08:00) [19]
To Explorer © (14.10.02 13:48)

>Т.е. получается, что если хочу по 20-ти сотрудникам, то мне
>в in указывать (1, 2, ... 20), так что ли?

WHERE id_сотрудники IN (1,2,3..20) - это не количество сотрудников, а их ID. Может быть и WHERE id_сотрудники IN (2,5,7,14,32,33,40) и т.д.

>А как их (20 сотрудников) программно загнать в запрос?
Вот ты их уже и загнал. (см. выше).

Explorer (2002-10-14 13:58:00) [20]
Max Zyuzin ©

мое незнание :))
А как их (20 сотрудников) программно загнать в запрос?
Если можно, то примерчик?

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

Наверх

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