SQL запрос

← →
Sokoloff (2002-06-03 13:21) [0]

Кто делал нечто подобное, подскажите как сделать зарос.

Есть таблица
ID_TOVAR | DATE | COUNT ----------------------------- 1 | 01.01.2002 | 100 2 | 01.01.2002 | 50 1 | 02.01.2002 | 200 3 | 02.01.2002 | 75 ...
Где:
ID_TOVAR - ID товара
DATE - дата продажи
COUNT - количество проданого товара

Нужно построить SQL запрос, чтоб вывод был в виде

| продано | продано | ID_TOVAR | 01.01.2002 | 02.01.2002 | ... ---------|------------|------------| 1 | 100 | 200 | 2 | 50 | | 3 | | 75 | ...

Количество типов товаров меняется, количество дней, само собой.
Запрос типа
SELECT my_tbl01.count, my_tbl02.count FROM my_table my_tbl01, my_table my_tbl02 WHERE my_tbl01.id_tovar=my_tbl02.id_tovar and my_tbl01.date="01.01.2002" and my_tbl02.date="02.01.2002"
Показывает только строку для товара ID_TOVAR=1.
Как мне кажеться надо использовать JOIN, но что-то у меня толком не получается :(
Кто может, подскажите плз.

← →
Alexandr (2002-06-03 13:29) [1]

количество типов товаров - фигня, хуже с количеством столбцов:
тут уж или зафиксировать , или на клиенте запрос строить автоматически.

а пример нельзя т.к. запутался я что у тебя в myu_tbl01, и что в my_tbl02

← →
kaif (2002-06-03 13:39) [2]

1. Во-первых, не называй поля COUNT и DATE,
а например SALE_COUNT и SALE_DATE.
2. Во-вторых, подсчет проданного количества SUM(SALE_COUNT) требует группировки GROUP BY по ID_TOVAR и SALE_DATE:
SELECT
ID_TOVAR, SALE_DATE, SUM(SALE_COUNT)
FROM
MY_TABLE
WHERE
SALE_DATE BETWEEN :DATE1 AND DATE2
GROUP BY
ID_TOVAR, SALE_DATE
3. Потом эту нормальную таблицу лучше превращать в ненормальную (с колонками SALE_DATE) уже в приложении, при отображении данных. Если, конечно, ты не хочешь получить крайне низкие скорости.
-------------
Если же есть желание, тем не менее, устроить себе гимор с многоколоночным запросом, то тут нужно думать... Многое зависит от того, сколько колонок дат предполагается иметь. Если 2-7, то это одно дело, если 156, то я не знаю вообще, возможно ли такое без значительной потери скорости.
А вообще, скорость - важный момент. Кол-во записей обычно имеет тенденцию расти.

← →
yozhik (2002-06-03 13:44) [3]

с IB не работал :(, но в аксесе есть перекрестный запрос, делает то что надо, без каких либо ограничений на кол-во столбцов, поищи может есть что подобное.

← →
Sokoloff (2002-06-03 13:55) [4]

To Aleksandr:

> количество типов товаров - фигня, хуже с количеством столбцов:
> тут уж или зафиксировать , или на клиенте запрос строить
> автоматически.
>

Про количество товаров и дат, я написал именно потому, что нельзя зафиксировать кол-во столбцов. Запрос я и так собираюсь строить динамически, потом нужно будет накладывать
дополнительные ограничения, на диапазон дат, виды товаров и.т.д.

To kaif

> 1. Во-первых, не называй поля COUNT и DATE,
> а например SALE_COUNT и SALE_DATE.

Реально они называются подругому - это только пример, да и сама таблица несколько сложнее.

> 2. Во-вторых, подсчет проданного количества SUM(SALE_COUNT)
> требует группировки GROUP BY по ID_TOVAR и SALE_DATE:
> SELECT
> ID_TOVAR, SALE_DATE, SUM(SALE_COUNT)
> FROM
> MY_TABLE
> WHERE
> SALE_DATE BETWEEN :DATE1 AND DATE2
> GROUP BY
> ID_TOVAR, SALE_DATE

Мне НЕ нужно считать сумму, мне нужно создать "ненормальную таблицу" с несколькими столбцами.

> 3. Потом эту нормальную таблицу лучше превращать в ненормальную
> (с колонками SALE_DATE) уже в приложении, при отображении
> данных. Если, конечно, ты не хочешь получить крайне низкие
> скорости.

Т.е. ты считаешь, что хитрый SQL запрос будет работать медленнее чем запрос+парсинг данных. Может и так, тогда проблем нет, буду раскидывать данные у клиента.

← →
kaif (2002-06-03 14:00) [5]

В MSSQL есть конструкции типа CUBE для получения таких вещей.
Можно попробовать использовать нормальный запрос + несколько глюкавый компонент TDecisionCube Delphi.
А лучше всего - нормальный запрос плюс экспорт в Excel. Я бы так сделал. Это проще всего и быстее всего будет работать. И к тому же при печати можно будет руками настроить Excel так, чтобы отчет в лист бумаги поместился. Ведь все равно, даже если ты его умудришься сделать на чистом SQL, тебя потом попросят все это печатать. А теперь представь себе такую перспективу!!... Скажем, берем QuickReport и rutime пихаем в него компоненты TQRLabel и т. п., рассчитываем, как это все влезет в печатаемый лист, если нужно ставим ландшафтную печать и т. д.
Все равно придешь к экспорту в Excel.
Так не лучше сразу из этого и исходить?
Зачем сервер мучить несвойственными для него задачами? Серверу - серверово. Пусть он данные выбирает. А уж как их расставлять по отчету, зачем ему об этом думать?

SQL запрос Найти похожие ветки