Перекомпоновать таблицу в SQL запросе

← →
normandia (2004-05-09 21:34) [0]

Есть таблица со следующей структурой
OBJ PARAM ZNAHC
--------------------------
объект1 1 3.2
объект1 2 5.7
объект2 1 4.5
объект2 2 6.3

Данные таблицы надо отобразить в виде

OBJ PARAM1 PARAM2
--------------------------
объект1 3.2 5.7
объект2 4.5 6.3

Xотелось бы получить результат через SQL запрос.
Можно ли это сделать? Если можно, прошу подсказать как (с примером).

Заранее благодарю.

← →
sniknik © (2004-05-09 23:12) [1]

SELECT a.OBJ, a.ZNAHC AS PARAM1, b.ZNAHC AS PARAM2
FROM Table1 a INNER JOIN Table1 b ON a.OBJ=b.OBJ AND a.PARAM<b.PARAM

благодарность надо не заранее, надо в литрах, можно по почте.

← →
Курдль © (2004-05-10 00:52) [2]

> благодарность надо не заранее, надо в литрах, можно по почте.

За такой совет, как в [1], в литрах не получтся. Задача сложнее т.к. под "таблицей со следующей структурой" понималась именно структура, а не данные. Так что при появлении 3-го параметра Ваш запрос не сработает :(
http://delphimaster.net/view/3-1083242996/

← →
Johnmen © (2004-05-10 01:13) [3]

>normandia

Требуется внятное изложение того, что надо....
Из приведённого примера это не ясно...

← →
sniknik © (2004-05-10 09:56) [4]

почему не сработает? сработает, только результат будет неадекватен, не то что ожидалось. естественно, под другие условия другой запрос.

← →
normandia (2004-05-10 18:58) [5]

2 Johnmen
Вопрос поставлен вполне внятно. Другие поняли совершенно верно и даже подсказали в тему.
В результирующей таблице для каждого объекта должна быть одна строка со списком всех параметров. А в исходной таблице для каждого параметра одна строка. Вот и все.
В общем виде параметров может быть и больше двух.
У меня около 10. Это как раз рассмотрено в
http://delphimaster.net/view/3-1083242996/

Уважаемый Курдль меня отослал туда, куда нужно:)
Все заработало, только пока медленно.
Почему-то left join делает неиндексированное чтение,
а записей более 100000. Поэтому обрабатывается долго.
Индексы вроде все нужные есть. Пытаюсь разобраться.

А так спасибо (3 литра):)

← →
normandia (2004-05-10 20:33) [6]

Все заработало!
Вместо left join по какому-то наитию поставил просто join.
Оптимизатор сам составил план запроса с использованием нужного индекса. Все залетало мухой. (кстати я поскромничал, в моей базе около 2 000 000 записей)

Попутно назрел вопрос.
А чем таким особенным отличаются left join и простой join с точки зрения использования индексов?
А то сделать то сделал, но только это было чистое шаманство:) (то есть знаю как добиться результата, но не знаю как это работает).
Неприятно так программы писать.

Я в том обсуждении, ссылку на которое дал, предлагал вариант без join-ов. Проверь - самому интересно, быстрее, или нет.

Интересно, а как будет работать Ваш иннер джойн, если у какого-то из объектов отсутствует хотя бы один из 10 параметров? Или Вас устраивет, если такие объекты пропадут?
И почему именно такая организация хранения данных? Я, когда только начинал работать с IB, самую первую свою базу данных тоже так организовал. Но потом больше никогда так не делал.
:)
Я не то, чтобы настаиваю, что так неправильно. Просто хотелось бы услышать, почему это сделано именно так?

← →
normandia (2004-05-11 12:13) [9]

2 Курдль
Вариант без join по быстродействию работает абсолютно также (время выполнения запроса ~15ms).

Вообще, я так понял, что вариант с join появился потому,что в ветке форума, на которую была дана ссылка, рассматривалась база с тремя, а не сдвумя таблицами:
1. Список объектов с указанием их типов.
2. Список возможных типов параметров с указанием их имен и приналежности каждого параметра к определенному типу объекта.
3. Список значений с указанем объекта и типа параметра.

join был применен потому, что выбор из таблицы 2 делается по имени параметра, а информации об имени в таблице 3 нет, есть только ID типа параметра.

Я сделал запрос по ID параметра (как предлагал Курдль), теперь необходимость в join отпала.

2 kaif
Такая структура нужна, если набор параметров объекта определенного типа может время от времени меняться. Тогда все сводится к изменениям в таблице 2. При этом количество доступных параметров определяется отдельным запросом, а потом программно набирается окончательный запрос.

Кстати, если какого-либо необходимого параметра нет, запрос работает правильно. А именно, соответствующее поле в строке результата будет равно NULL. Сам объект из выборки не исчезает.
Именно так и надо.

Вообще-то эта база досталась мне в готовом виде (только на Paradox 3.5). Заказчику надо было перегнать ее в IB и переписать программу доступа.

Перекомпоновать таблицу в SQL запросе Найти похожие ветки