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

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

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

Запрос не объединение таблиц [D7, IB6.x]

Страницы: 1 2 >
ASVShade © (2005-09-05 03:14:00)
Есть две таблицы 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

ASVShade (2005-09-16 01:30:00) [1]
Сервер точно зависал уж думать 5 мин над запросм бреддд. причём изменив звёздочку на названия полей вообще не думал.
Разработчикам писать нафиг мне это нужно

1. Версия IB/FB - Firebird-1.0.3.972-Win32
2. Кол-во записей в таблицах, используемых в запросе. - T1-24000, T2-11000
3. Индексы в этих таблицах - на всех полях
4. План запроса и сам запрос - план запроса указан в перов посте и запрос тоже

Про битые индексы впервые слышу. Слышал что они со временем (само двоичное дерево) немного тормознутыми становятся и их пересоздать нужно... но про битые первый раз.

Zacho (2005-09-09 21:02:00) [2]
ASVShade © (09.09.05 20:05) [20]

Если тебе нужны именно все поля, то естественно можешь использрвать *

И всё-таки, вряд ли сервер у тебя именно "зависал". Скорее всего, просто он очень долго выполнял этот запрос. А если уверен, что именно "зависал" - пиши багрепорт разработчикам.
И не мешало бы всё-таки привести информацию, которую я спрашивал в [16]

Кстати,
ASVShade © (09.09.05 2:14) [18]
Они только работу ускоряют, но на качество не влияют

Могут и "влиять на качество". Например, если индексы "битые".

ASVShade (2005-09-09 20:05:00) [3]
А если у меня полей штук 15, все нужно перечислять?
И как интересно я его гроблю?

Anatoly Podgoretsky (2005-09-09 09:12:00) [4]
ASVShade © (09.09.05 02:14) [18]
select *такая конструкция крайне не рекомендуется, гробишь сервер.

ASVShade (2005-09-09 02:14:00) [5]
Огромное спасибо:

"
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-07 20:37:00) [6]
ASVShade_ (06.09.05 08:39) [15]
Я не про это при указаныз данныз результат по количество строк должен быть другой.

Zacho (2005-09-07 20:24:00) [7]
Ну, и как результаты ?

Если всё ещё сервер "виснет", то приведи полную информацию, а именно:

1. Версия IB/FB
2. Кол-во записей в таблицах, используемых в запросе.
3. Индексы в этих таблицах
4. План запроса и сам запрос.

ASVShade_ (2005-09-06 08:39:00) [8]
To Anatoly Podgoretsky

Точно это опечатался вместо
T1.id T1.us T1.mark T2.id T1.mark

Должно быть
T1.id T1.us T1.mark T2.id T2.mark

Очтальные советы сейчас попробую реализовать!

ANB (2005-09-05 15:57:00) [9]

> Anatoly Podgoretsky © (05.09.05 15:53) [13]
- да вроде де бы обычный лефт джойн. Если поля правильно написать . . . А чего не так ?

Anatoly Podgoretsky (2005-09-05 15:53:00) [10]
ANB © (05.09.05 15:05) [12]
Данный результат противоречит реляционной алгебре, другими слова такой результат не возможен.

ANB (2005-09-05 15:05:00) [11]

> 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 13:10:00) [12]
ANB © (05.09.05 10:45) [7]
- тут явная очепятка.

2 3 2 3 2 7 3 2 8 2

И это тоже опечатка?

Ильш (2005-09-05 11:27:00) [13]
о ё... точно есть же id, не заметил ;)
тогда афтарр ПЛАН камон сюды!!! :)
сикока записсей в таблах?

ANB (2005-09-05 11:18:00) [14]

> Ильш © (05.09.05 11:12) [8]
- не факт и в данном случае - вовсе не обязательно.

Ильш (2005-09-05 11:12:00) [15]

> T2.mark - поле уникальное

если поглядеть ваще то T1.mark должно быть уникальным

ANB (2005-09-05 10:45:00) [16]

> Anatoly Podgoretsky © (05.09.05 09:39) [4]
- тут явная очепятка.

> Zacho © (05.09.05 10:02) [6]
- сильно хуже не будет, мало ли как потом база развививаться будет. Имхо. Вообще - совет правильный.

Zacho (2005-09-05 10:02:00) [17]
Дополню ANB © (05.09.05 9:20) [3]:

Если количество разных значений в us невелико, то индекс на us лучше не создавать.

И приведи здесь план запроса.

Desdechado (2005-09-05 09:51:00) [18]
не забываем вместо * в SELECT указывать список полей с таблицами, откуда их взять

Anatoly Podgoretsky (2005-09-05 09:39:00) [19]
ASVShade © (05.09.05 03:14)
T1.id T1.us T1.mark T2.id T1.mark 3 3 3 null null
Это не возможно

ANB (2005-09-05 09:20:00) [20]

> ASVShade © (05.09.05 07:57) [2]
- проверь наличие индексов :
На T1 - mark, us
На T2 - mark
В остальном оптимален запрос ЮЮ © (05.09.05 04:09) [1]

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

Наверх

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