Архив форумов ЦИТФорума

[Som]

Привет великий All!

В общих словах задача о повороте таблиц на 90 градусов.

А конкретнее:

есть две таблицы в MsSQL2000:

первая:
_____________________
Код Тип Значение
---------------------
1 1 10
1 3 1.01.01
2 2 1000
3 2 1000
3 1 2

вторая:
______________
Код Значение
--------------
1 Город
2 Код клиента
3 Дата

Они связаны: Первая.Тип = Вторая.Код

Как эти две таблицы преобразовать в такую:
________________________________________
Код Город Код клиента Дата
----------------------------------------
1 10 NULL 1.01.01
2 NULL 1000 NULL
3 2 1000 NULL

Как вы заметили(а может и нет ) вторая таблица есть ничто иное как список колонок, а в первой записаны значенния.
Вся проблема в том, чтобы была возможность динамически менять количество колонок в третьей таблице.
Если есть возможность то третью таблицу оформить как процедуру или функцию.

PS Заранее благодарен за ответы

[Евгений Григорьев]

...потому как я, чесс говоря, кое-что не понял. Какие таблицы - понял, как связаны - тоже понял. Не понял следующее
1) почему в первой таблице в третьем столбце встречаются и цифры и даты?
2)если вторая таблица - это список колонок, то зачем они связаны по атрибуту?
3)Еще раз повторите, что надо сделать - только подробнее. Может быть саму задачу сформулировать?

Навскидку же могу сказать, что такие вещи выходят за рамки реляционной алгебры. Ну нельзя там такое - хоть тресни. Определние отношения(в миру называемого таблицей), состоящего, говоря условно, из заголовка (названия столбцов) и тела (множество записей), является одной из аксиомой теории реляционной БД - на которых она сосбсно и строится. И никаких таких операций, где информация из тела вдруг переходит в заголовком или наоборот, там нет.

На самом деле это конечно же не значит, что в конечных продуктах такое невозможно. Каждый извращается по своему. Например тот же MS Access имеет SQL иструкцию TRANSFORM результатом действия которой является перекресный запрос, где значения из записей как раз попадают в столбцы. Но это нестандартный SQL, и, если я не ошибаюсь, ничего подобного в MS SQL сервере нет (во всяком случае в книжке по нему я этого не нашел). То есть ИМХО такие штуки надо делать руками.

Мне кажеться, что такие вещи имеют больше отношения уже к ВИЗУАЛИЗАЦИИ информации, и должны выполняться поближе к пользователю - то есть на клиенте.

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

Во, блин накатал,

[Som]

И вам привет!

1) Цифры и даты: тип nvarchar вот и всё
Это когда мы их достанем они станут цифрой
и датой и не только ими ...
2) Вторая - писок колонок,а в первой показано
что, в какой колонке должно быть ...
3) Перефразирую: допустим у нас есть писок
товаров и цен на эти товары.
Всё прекрасно, но цена на один и тот же
товар может быть разной и зависеть от
даты, клиента ... фаз луны, вчерашней
погоды шучу факт в тот, что условий
может быть неограниченное количество (((
И число их неизвестно на момент создания
базы.

PS Это дело я организовал через динамические
запросы и временную таблицу
Но помоему это как-то криво смотрится
Так что, если есть идеи - подкинть плиз

[Евгений Григорьев]

Ну и?

Есть такая штука - нормализация называется (я конечно понимаю, что ты в курсе, но все же напомнить в данном случае - не лишнее). Так вот! есть такая штука - нормализация. Ежели попытаться применить ее к данному конкретному случаю, то может получается вполне сносная (в реляционном плане весчь. Например!

Делаем две таблицы. Одна таблица - список ТОВАРОВ, вторая таблица - ЦЕНЫ для этих товаров (эти таблицы связаны). Ессесно, что каждого товара во второй таблице может быть очень много разных цен - например для каждого клиента своя цена. Для этого таблицу ЦЕН надо связать с таблицей КЛИЕНТОВ. Если пораскинуть мозгами, то можно сбацать также таблицу УСЛОВИЯ (те самые фазы луны ). Если связать и ее с таблицей ЦЕН, то можно иметь для каждого клиента на любой товар также много цен - в зависимости от тех или иных условий. И т.д. и т.п.

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

Или я что-то не так понял?

[Som]

Привет!

Если я правильно Вас понял, Вы предлагаете для
каждого условия вводить свои таблицы? И как же они должны быть связаны? Вводить новые поля?
А как быть с периодом по времени? Тут же фигурируют две даты

Ещё раз повторюсь: я не знаю сколько этих условий будет и как они будут между собой связаны

[Old_Den]

...что тебе дано, что надо получить.
А то каждый мыслит в своем контексте и до конца "не втыкается" в смысл слов собеседника.

[Som]

Есть товар, есть цена на товар.
Первоначально она может быть одна.
Но тут появляеться клиент и заключает договор.
А в договоре говориться, что товар с 1-ого по 3-е по одной цене, в пятницу 13-ого по второй, а если он его покупает его в городе N, то по третьей, так как ему оттуда ближе возить.
И таких клиентов много с разными условиями.
Да и цена может зависеть не только от клиента, например в одном городе она одна, а в другом другая.

Так вот:
Дано: ТОВАР
Незвестно: Хi - условия, где i = 1..n
n - неизвестное количество словий
Нужно: Найти отношение ЦЕНА(ТОВАР,Xi) = Yк
где Yk - цена, которая зависит от
товара и произвольного набора условий

Другими словами: как построить взаимосвязь
между ценою и товаром через
произвольный набор условий.

PS ну не знаю как вам ещё обьяснить

[Евгений Григорьев]

....Ну почему???(с)Крокодил Гена(если не ошибаюсь)

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

Ну а если речь идет о представлении данных в виде таблицы где строки - товары, столбцы условия, а в клеточках пишешь цены, то это либо извращаться, либо пользоваться системой типа ACCESS с оператором TRANSFORM.

Ну я не знаю как еще объяснять. То, как изначально стоит задача - это ИМХО вообще не очень реляционная система, поскольку атрибуты не атомарны. Я имею в виду столбец, где могут быть даты и числа одновременно (и как я понял и еще что-то). То есть они атомарны по букве, (поскольку все они есть строки), но не по духу - поскольку реально содержат разнотипную информацию - т.е. информацию из разных доменов. И как только ты пытаешься эту разнотипность поймать (а именно это ты пытаешься сделать, отделив даты от чисел)- так сразу начинаются проблемы.

[Евгений Григорьев]

Я все равно не понимаю, зачем их (эти условия) обязательно выписывать в виде развернутой таблицы? Только для посмотреть? Я просто не вижу иной разумной причины.

[Som]

Если бы одно условие на одну цену!!!
Тогда бы и этого разговора не было бы
В моём случае сума условий (и каждый раз разных) на одну цену

И на эту проблему я смотрю не только как разработчик базы, но и как программер. Ведь нужно сделать гибкую систему, которая бы не зависела от количества условий и их комбинаций.
И "развёрнутую" таблицу я делал исходя из этого. Ведь проще сгенерить динамический запрос с расширяемым условием WHERE. Чем копаться в трёх таблицах.
Но это не о том. Я ведь просто хочу узнать,
как лучше это дело можно реализовать.

С уважением.

[Евгений Григорьев]

Я про это сразу так и сказал. А потом я сказал, что мое глубочайше ИМХО, что там это и не к чему. Вот получишь ты такую развернутую таблице с заранне неопределенным количеством и даже названиями столбцов - что ты с ней делать дальше собираешся? ИМХО ее только и можно что посмотреть, потому как в данном случае нельзя заранее определить какой-нить вид или процедуру, работающие с данными представленными в таком виде. ... то есть процедуру можно - но это уже такое извращение будет! )

[Som]

... вот загнать в неё данные, это есть полным "извратом"

Использовать её тоже просто, ведь нам из неё нужно вынуть только цену. А в операторе WHERE по циклу генериш все условия, вроде всё просто.

Вот мне и захотелось узнать другие пути решения задачи... так как сам зациклился на этом

[BiS]

зачем разворачивать таблицу???
ни в одной базе так не издеваются!
лучше завести таблицу с несколькими колонками,
в первой колонке название поля, во второй тип, если надо, в третьей значение, в четвертой порядковый номер.
И как главное работать будешь с такой таблицей?

По идее, если нужно только для отчета, то должны быть в построителях отчетов средства организовать такие выборки.