Текущий архив: 2005.10.30;
Скачать: CL | DM;
ВнизЗапрос не объединение таблиц Найти похожие ветки
← →
ASVShade © (2005-09-05 03:14) [0]Есть две таблицы T1,T2
Таблицы связаны полем mark
T1.mark=T2.mark
T2.mark - поле уникальное
Запись удовлетворяющая условию T1.mark=T2.mark как может присутствовать в таблице T2 так и нет.
Нужно сформировать запрос возвращающий записи из обоих таблиц.
Если запись в таблице T2 есть то вернуть нужно данные как вернёт запрос
select *
from T1,T2
where (T1.mark=T2.mark) and (T1.us=:us)
Если записи в таблице T2 нет то вернуть нужно данные таком же формате как и выше, единственное все поля из таблицы T2 заменить например на NULL
Пример результата работы нужного запроса: (где us=3)
T1.id T1.us T1.mark T2.id T1.mark
1 3 1 1 1
2 3 2 3 2
3 3 3 null null
4 3 3 null null
5 3 4 2 4
6 3 5 null null
7 3 2 8 2
← →
ЮЮ © (2005-09-05 04:09) [1]убрать (T1.mark=T2.mark) из WHERE туда, куда следует, именно в условие объединения, а WHERE оставить исключетельно для отбора:
select *
from
T1
left join T2 on (T1.mark=T2.mark)
where (T1.us=:us)
← →
ASVShade © (2005-09-05 07:57) [2]Пробывал, но тогда сервак виснет. Задумывается на очень долго только ctrl+alt+delete помогает
← →
ANB © (2005-09-05 09:20) [3]
> ASVShade © (05.09.05 07:57) [2]
- проверь наличие индексов :
На T1 - mark, us
На T2 - mark
В остальном оптимален запрос ЮЮ © (05.09.05 04:09) [1]
← →
Anatoly Podgoretsky © (2005-09-05 09:39) [4]ASVShade © (05.09.05 03:14)
T1.id T1.us T1.mark T2.id T1.mark
3 3 3 null null
Это не возможно
← →
Desdechado © (2005-09-05 09:51) [5]не забываем вместо * в SELECT указывать список полей с таблицами, откуда их взять
← →
Zacho © (2005-09-05 10:02) [6]Дополню ANB © (05.09.05 9:20) [3]:
Если количество разных значений в us невелико, то индекс на us лучше не создавать.
И приведи здесь план запроса.
← →
ANB © (2005-09-05 10:45) [7]
> Anatoly Podgoretsky © (05.09.05 09:39) [4]
- тут явная очепятка.
> Zacho © (05.09.05 10:02) [6]
- сильно хуже не будет, мало ли как потом база развививаться будет. Имхо. Вообще - совет правильный.
← →
Ильш © (2005-09-05 11:12) [8]
> T2.mark - поле уникальное
если поглядеть ваще то T1.mark должно быть уникальным
← →
ANB © (2005-09-05 11:18) [9]
> Ильш © (05.09.05 11:12) [8]
- не факт и в данном случае - вовсе не обязательно.
← →
Ильш © (2005-09-05 11:27) [10]о ё... точно есть же id, не заметил ;)
тогда афтарр ПЛАН камон сюды!!! :)
сикока записсей в таблах?
← →
Anatoly Podgoretsky © (2005-09-05 13:10) [11]ANB © (05.09.05 10:45) [7]
- тут явная очепятка.2 3 2 3 2
7 3 2 8 2
И это тоже опечатка?
← →
ANB © (2005-09-05 15:05) [12]
> Anatoly Podgoretsky © (05.09.05 13:10) [11]
- точно очепятка. В заголовке. Должно быть :
T1.id T1.us T1.mark T2.id T2.mark
1 3 1 1 1
2 3 2 3 2
3 3 3 null null
4 3 3 null null
5 3 4 2 4
6 3 5 null null
7 3 2 8 2
← →
Anatoly Podgoretsky © (2005-09-05 15:53) [13]ANB © (05.09.05 15:05) [12]
Данный результат противоречит реляционной алгебре, другими слова такой результат не возможен.
← →
ANB © (2005-09-05 15:57) [14]
> Anatoly Podgoretsky © (05.09.05 15:53) [13]
- да вроде де бы обычный лефт джойн. Если поля правильно написать . . . А чего не так ?
← →
ASVShade_ (2005-09-06 08:39) [15]To Anatoly Podgoretsky
Точно это опечатался вместо
T1.id T1.us T1.mark T2.id T1.mark
Должно быть
T1.id T1.us T1.mark T2.id T2.mark
Очтальные советы сейчас попробую реализовать!
← →
Zacho © (2005-09-07 20:24) [16]Ну, и как результаты ?
Если всё ещё сервер "виснет", то приведи полную информацию, а именно:
1. Версия IB/FB
2. Кол-во записей в таблицах, используемых в запросе.
3. Индексы в этих таблицах
4. План запроса и сам запрос.
← →
Anatoly Podgoretsky © (2005-09-07 20:37) [17]ASVShade_ (06.09.05 08:39) [15]
Я не про это при указаныз данныз результат по количество строк должен быть другой.
← →
ASVShade © (2005-09-09 02:14) [18]Огромное спасибо:
"
Desdechado © (05.09.05 09:51) [5]
не забываем вместо * в SELECT указывать список полей с таблицами, откуда их взять
"
При вызове запроса типа
select *
from
T1
left join T2 on (T1.mark=T2.mark)
where (T1.us=:us)
сервак вис. Добавив поля всё стало работать.
Кстати индексы тут не при чём. Они только работу ускоряют, но на качество не влияют
На этом тему считаю закрытой.
Всем спасибо!
← →
Anatoly Podgoretsky © (2005-09-09 09:12) [19]ASVShade © (09.09.05 02:14) [18]
select *
такая конструкция крайне не рекомендуется, гробишь сервер.
← →
ASVShade © (2005-09-09 20:05) [20]А если у меня полей штук 15, все нужно перечислять?
И как интересно я его гроблю?
← →
Zacho © (2005-09-09 21:02) [21]ASVShade © (09.09.05 20:05) [20]
Если тебе нужны именно все поля, то естественно можешь использрвать *
И всё-таки, вряд ли сервер у тебя именно "зависал". Скорее всего, просто он очень долго выполнял этот запрос. А если уверен, что именно "зависал" - пиши багрепорт разработчикам.
И не мешало бы всё-таки привести информацию, которую я спрашивал в [16]
Кстати,
ASVShade © (09.09.05 2:14) [18]
Они только работу ускоряют, но на качество не влияют
Могут и "влиять на качество". Например, если индексы "битые".
← →
ASVShade © (2005-09-16 01:30) [22]Сервер точно зависал уж думать 5 мин над запросм бреддд. причём изменив звёздочку на названия полей вообще не думал.
Разработчикам писать нафиг мне это нужно
1. Версия IB/FB - Firebird-1.0.3.972-Win32
2. Кол-во записей в таблицах, используемых в запросе. - T1-24000, T2-11000
3. Индексы в этих таблицах - на всех полях
4. План запроса и сам запрос - план запроса указан в перов посте и запрос тоже
Про битые индексы впервые слышу. Слышал что они со временем (само двоичное дерево) немного тормознутыми становятся и их пересоздать нужно... но про битые первый раз.
Страницы: 1 вся ветка
Текущий архив: 2005.10.30;
Скачать: CL | DM;
Память: 0.5 MB
Время: 0.058 c