Представление данных

← →
ilya1974 © (2002-10-22 16:48) [0]

Здравствуйте.
Есть вопрос: существует некое меняющееся кол-во складов, на которых хранится разное количество товаров. Информация о количестве товара на каждом складе храниться в базе в виде записи:
Wrh_Id Goods_Id Goods_Qty
где wrh_id - номер склада, goods_id - номер товара, goods_qty - количество товара goods_id на складе wrh_id. Комбинация goods_id+wrh_id уникальна.
Внимание, вопрос:
Как организовать вывод в grid данные в одном SQL-запроосе о кол-ве товара в виде:
Товар 1 Кол-во1 Кол-во2 Кол-во3 ... Итого по товару 1
Товар 2 Кол-во1 Кол-во2 Кол-во3 ... Итого по товару 2

Кол-во1, Кол-во2... - количество товара на соответствующем складе.

Едитнственное решение, которое я вижу - организовать временную таблицу, а затем в цикле перебирать все склады, для каждого из них занося данные в соответствующие столбцы SQL-запросом. Но это как-то криво. Как быть?

← →
Johnmen © (2002-10-22 17:10) [1]

Временная таблица может и кривоватое решение, но в данном случае оправдана (хотя бы быстродействием). Еще лучше не временная таблица в БД, а виртуальная в памяти...

← →
MsGuns © (2002-10-22 17:31) [2]

А почему бы не сделать эту "солянку":
> Товар 1 Кол-во1 Кол-во2 Кол-во3 ... Итого по товару 1
> Товар 2 Кол-во1 Кол-во2 Кол-во3 ... Итого по товару 2

не горизонтально, а вертикально, в виде дочерней таблицы, (точнее TQuery). В этом случае нет завязки на кол-во колонок (складов). А если все же надо в журнальном виде, то формировать в виде отчета или пихать в Excel.

Т.е. вид:

Основной грид

Товар 1 | Итого по товару 1 | Кол-во складов, где есть
Товар 2 | Итого по товару 2 | Кол-во складов, где есть

Детальный грид (по текущей позиции):

Склад 1 | Кол-во по текущей позиции
Склад 2 | Кол-во по текущей позиции

По-моему проще в программировании и не надо никаких временных таблиц.
Или надо обязательно "шахматку" ?

← →
ilya1974 © (2002-10-22 17:40) [3]

Да не так чтобы обязательно, но "шахматка" на порядок нагляднее.

← →
LordOfSilence © (2002-10-22 17:43) [4]

М-да...

Знаю как это сделать на Access, но, к сожалению,
у Вас формат базы не тот. Как сделать на Paradox -
врядли подскажу...

← →
Diouzshev (2002-10-22 17:50) [5]

Дык пихнуть в StringGrid и все...
20 строк кода....

← →
MsGuns © (2002-10-22 21:39) [6]

>ilya1974 © (22.10.02 17:40)
>Да не так чтобы обязательно, но "шахматка" на порядок нагляднее.

А вот это уже - дело привычки.
Но данную задачку еще можно решить "горизонтально", а вот как решить другую: показать в виде шахматки реализацию Товар-Клиент ?

И тех, и других может быть тысячи. Тоже гридом ? А ведь зато наглядно !

← →
ilya1974 © (2002-10-23 13:44) [7]

TO LordOfSilence

База реляционная, такой формат данных "идеалогически верен."
Если есть какие-нибудь соображения касательно формата хранения данных, прошу высказывать.

TO Diouzshev

Одним SELECT"ом не обойтись в любом случае.

TO MsGuns
Если количество складов невелико (до 4-5), "шахматка", наиболее наглядна. В реальной жизни даже крупная организация не имеет больше.

← →
MsGuns © (2002-10-23 14:17) [8]

>ilya1974 © (23.10.02 13:44)
>Если количество складов невелико (до 4-5), "шахматка", наиболее >наглядна. В реальной жизни даже крупная организация не имеет >больше.

Согласен. Тогда разметь грид на N колонок складов, гле N - max их кол-во. А при открытии TQuery перебирай поля складских остатков (их должно быть по кол-ву складов) и записывай в св-ва Field колонок. "Свободные" колонки просто ничего не будут содержать

← →
ilya1974 © (2002-10-23 14:23) [9]

Это надо делать LOCATE"ом, что во-первых неправильно, во-вторых сильно скажется на быстродействии. Выбирать поля нужно только SQL-ем

← →
mihey (2002-10-23 14:24) [10]

Даную задачу можна решить используя динамические массивы, или StringList, и использовать при этом StringDrid. Только пальчиками прийдётся потрудится.

> ilya1974 © (23.10.02 13:44)

"TO LordOfSilence
База реляционная, такой формат данных "идеалогически верен."
Если есть какие-нибудь соображения касательно формата хранения данных, прошу высказывать."

Извините, я сегодня совсем "отвязанный", поэтому не до конца
понял суть Вашего вопроса.
Если Вас интересуют теоретические аспекты в стиле
"а что круче Access, FoxPro или Paradox?" то сразу
скажу, что я не люблю участвовать в подобных дебатах.
Что именно для Вас "идеологически верно" - реляционность
баз данных вообще или выбранный Вами формат Paradox?
Могу Вам повторить то, что сказал ранее - я знаю как
это сделать в Access. Если Вас это заинтересовало,
то я Вам отвечу, но уже завтра, так как пора собираться
домой. Буду ждать Вашего постинга.

Идеалогически верен подход хранения данных в этом формате для любой реляционной БД, выполняется требование нормализации.
Если есть соображения касательно измения структуры хранения данных для облегчения программирования/отображения,то с удовольствием выслушаю. Заранее спасибо.

М-да...
Я так понял, что Вы начинаете потихоньку теоретизировать,
а мне меньше всего хочется сейчас этим заниматься.
Никаких соображений "касательно измения структуры хранения данных"
у меня нет, так как Вы лучше знаете свою задачу и Вам виднее
как определять таблицы, поля, связи, ссылочные целостности
и все-такое прочее.
Просто дело в том, что у Paradox (и его SQL-синтаксиса)
есть свои возможности и ограничения, а у Access, например,
(и его SQL-синтаксиса) - свои.
К сожалению, Вы не оставили своего почтового ящика ни в самой
обсуждаемой ветке, ни в своей анкете. Давайте сделаем так:
Вы связываетесь со мной по почте, а я Вам высылаю маленький
пример Access-базы с пояснениями, где составление подобного запроса является возможным и, в общем-то, не сложным.

Представление данных Найти похожие ветки