Форум: "Базы";
Текущий архив: 2002.06.27;
Скачать: [xml.tar.bz2];
Вниз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.
Так не лучше сразу из этого и исходить?
Зачем сервер мучить несвойственными для него задачами? Серверу - серверово. Пусть он данные выбирает. А уж как их расставлять по отчету, зачем ему об этом думать?
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.06.27;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.006 c