Select

← →
Explorer (2002-10-11 14:49) [0]

Мастера!
к примеру, есть две таблицы : сотрудники и задачи_сотрудников. Таблицы связаные по id_сотрудники.
На форме выбираю из общего списка таблицы_сотрудников, только некоторых (ex. "Иванов, Петров ") и хочу вывести по ним их задачи из таблицы_задачи_сот.
Подскажите, как можно такое реализоватьв запросе к БД?

← →
Johnmen (2002-10-11 14:57) [1]

вар.1. select на таблицы_задачи_сот, у которых id как у задачи_сотрудников
вар.2. фильтр на НД всех таблицы_задачи_сот по id

← →
Explorer (2002-10-11 15:17) [2]

а как в запросе перечислить все нужных мне сотрудников?
ведь их может быть или 5, или 25.. количество заранее не известно

← →
Max Zyuzin (2002-10-11 15:24) [3]

Динамически создавай запрос что то вроде
select * from задачи_сотрудников
where id_сотрудники in (1,2,3,4)
Вот этот список формируй в цикле по выбраным сотрудникам...

← →
PSERG (2002-10-12 08:42) [4]

select b.* from сотрудники a, задачи_сотрудников b where b.id = a.id and a.фамилия = "Иванов"

← →
Explorer (2002-10-14 13:48) [5]

>Max Zyuzin ©
Что-то я непонял?!

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

← →
Max Zyuzin (2002-10-14 13:55) [6]

>Explorer © (14.10.02 13:48)
Да, так :о) а что вас смущает?

← →
Explorer (2002-10-14 13:58) [7]

Max Zyuzin ©

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

← →
Hawk2 (2002-10-14 14:08) [8]

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 сотрудников) программно загнать в запрос?
Вот ты их уже и загнал. (см. выше).

← →
passm (2002-10-14 14:11) [9]

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"

← →
Max Zyuzin (2002-10-14 14:13) [10]

Ну... примерно так..

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);
Ну примерно так...

← →
PSERG (2002-10-14 15:01) [11]

Я все-же не понял. О чем вы разговор ведете. Это же тривиальный SQL запрос. То что вы предлагаете будет безбожно тормозить.
Мало того что использование IN в запросе не рекомендовано из-за тормозов, вы еще и советуете на уровне приложения бегать по набору данных и формировать строчку. ПОЛНАЯ ЧУШЬ!!!
Запос я написал несколько сообщений выше.

← →
Max Zyuzin (2002-10-14 15:07) [12]

>PSERG (14.10.02 15:01)
Пальцем пожалуйста ткните... а то я вашего запроса не наблюдаю...
И почему должно все это тормозить... объясните пожалуйста..

← →
MMF (2002-10-14 15:16) [13]

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

← →
passm (2002-10-14 15:20) [14]

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

← →
Johnmen (2002-10-14 15:23) [15]

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

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

← →
MMF (2002-10-14 15:28) [16]

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

← →
Max Zyuzin (2002-10-14 15:31) [17]

>PSERG (14.10.02 15:01)
Извиняюсь, ваш запрос нашел.
Но не понятно почему он должен рабоать быстрее...

← →
MMF (2002-10-14 15:36) [18]

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

← →
Johnmen (2002-10-14 15:48) [19]

>MMF © (14.10.02 15:36)

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

← →
MMF (2002-10-14 16:00) [20]

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

← →
Johnmen (2002-10-14 16:30) [21]

>MMF © (14.10.02 16:00)

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

← →
MMF (2002-10-14 16:46) [22]

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

← →
MMF (2002-10-14 16:52) [23]

← →
Johnmen (2002-10-14 16:53) [24]

← →
MMF (2002-10-14 17:00) [25]

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

← →
Explorer (2002-10-15 06:20) [26]

Всем большое спасибо!

Select Найти похожие ветки