Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Трансформация таблицы [D7, FireBird]

Страницы: 1 2 3 >
VitalikS © (2006-08-03 06:40:00)
Можно ли как-нибудь SQL запросом трансформировать таблицу (т.е. чтобы строки стали столбцами)?

Sergey13 (2006-08-04 16:04:00) [1]
> [40] ANB © (04.08.06 16:00)

Да кто бы спорил. Но эта задача, ИМХО, слабо подходит под "хранение переменного числа атрибутов". Особенно читая про

> Дело в том что данные о платежах храняться в таблице построчно
> (т.е. одна квитанция занимает от 4х строк: фамилия, л/с,
> сумма ....) у каждого элемента свой номер фамилия -16,
> сумма-1, л/с - 32 ........

ANB (2006-08-04 16:00:00) [2]

> Sergey13 © (04.08.06 15:58) [39]

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

Sergey13 (2006-08-04 15:58:00) [3]
> [38] ANB © (04.08.06 15:56)
> Кстати, прекрасная идея ! В некоторых случаях вполне применимо.
> Во всяком случае в АИС Налог физики и юрики лежат в одной
> таблице FN212.

Это что! У меня во всех программах в одной таблице лежат даже мужчины и женщины! О как! И не размножаются. 8-)))))))))

ANB (2006-08-04 15:56:00) [4]

> Ну давай все в одну табличку свалим и будем по кодам выбирать
> и товар и людей и основные средства.

Кстати, прекрасная идея ! В некоторых случаях вполне применимо. Во всяком случае в АИС Налог физики и юрики лежат в одной таблице FN212.

Sergey13 (2006-08-04 13:09:00) [5]
> [36] ANB © (04.08.06 11:57)

Ну давай все в одну табличку свалим и будем по кодам выбирать и товар и людей и основные средства. 8-) ИМХО тоже.

Кроме того
>И если появится еще один придется альтерить табличку. Некузяво.
Это за отдельную плату - сколько угодно с превеликим удовольствием. 8-)

ANB (2006-08-04 11:57:00) [6]

> Не совсем своя Москва придумала.

Правильно придумала

> в которой были бы все возможные реквизиты

И если появится еще один придется альтерить табличку. Некузяво.

Все имхо.

Виталий Панасенко (2006-08-04 10:45:00) [7]
Если, конечно, вся проблема в визуализации для клиента...

Виталий Панасенко (2006-08-04 10:44:00) [8]
NXDBGRID не поможет Отцу русской демократии ?

Danilka (2006-08-04 09:26:00) [9]
[30] VitalikS (04.08.06 08:36)
Основная поблема, на мой взгляд, не в скорости регистрации документов. И не в размерах БД.
А в скорости формирования различных отчетов.
Твой вариант, предложеный Москвой, будет наиболее тормозной, из всех возможных.
Можно было-бы сделать так, как в [31], или несколько таблиц: одна с обязательными реквизитами от всех, другая - по твоему варианту, с тремя полями: ид из первой таблицы, ид реквизита и значение реквизита, для редко используемых кем-то, экзотических реквизитов.
Если переделать структуру базы возможности нет, то только два варианта - тащить на клиента как есть, и уже там строить отчет, либо запросом разворачиваьт каждый реквизит, например, как из упоминаемой мною статьи Тенцера:

SELECT O.Id, S1.Value AS Family, S2.Value AS FirstName, S3.Value AS LastName, H.ItemDate AS BirthDate FROM Objects O INNER JOIN ObjType OT ON OT.Id = O.TypeId LEFT JOIN Strings S1 ON O.Id = S1.ObjectId LEFT JOIN StrDesc SD1 ON S1.TypeId = SD1.Id LEFT JOIN Strings S2 ON O.Id = S2.ObjectId LEFT JOIN StrDesc SD2 ON S2.TypeId = SD2.Id LEFT JOIN Strings S3 ON O.Id = S3.ObjectId LEFT JOIN StrDesc SD3 ON S3.TypeId = SD3.Id LEFT JOIN History H ON O.Id = H.ObjectId LEFT JOIN Status S ON H.TypeId = S.Id WHERE OT.Code = ‘PEOPLE’ AND SD1.Code = ‘FAMILY’ AND SD2.Code = ‘FIRSTNAME’ AND SD3.Code = ‘LASTNAME’ AND S.Code = ‘BIRTHDATE’

mr.il (2006-08-04 09:15:00) [10]
Если выпихнуть исходные данные в Excel и наложить сводную таблицу?

Sergey13 (2006-08-04 08:57:00) [11]
> [30] VitalikS (04.08.06 08:36)
> Ничего не поделаешь, а как бы ты организовал такое?
> Под схемой понимается различные элементы в квитанции.
Я бы сделал таблицу плательщиков/получателей и таблицу платежей, в которой были бы все возможные реквизиты. Если реквизит не заполнен, то и не печатается/не обрабатывается.

VitalikS (2006-08-04 08:36:00) [12]

> просто интересно, это по-мотивам статьи Анатолия Тенцера
> "БД – хранилище объектов", или какая-то собственная выдумка?
>

Не совсем своя Москва придумала. Мы подстраиваемся. Да и универсально вроде, можно принимать платежи от разных организаций с их потребностями.
> Удаление гланд электродрелью через .... Вобщем - я тащусь
> от такой "универсальности"

Ничего не поделаешь, а как бы ты организовал такое?
> по заранее известной схеме (для каждой организации своя)

Под схемой понимается различные элементы в квитанции.

Sergey13 (2006-08-04 08:18:00) [13]
> [27] VitalikS (04.08.06 04:34)
ИМХО.
Удаление гланд электродрелью через .... Вобщем - я тащусь от такой "универсальности"
> по заранее известной схеме (для каждой организации своя)

Danilka (2006-08-04 08:00:00) [14]
[27] VitalikS (04.08.06 04:34)
чуть кофием не подавился.
просто интересно, это по-мотивам статьи Анатолия Тенцера "БД – хранилище объектов", или какая-то собственная выдумка?

VitalikS (2006-08-04 04:34:00) [15]
Уфффф...
Спасибо всем кто отвечал

> то наверное называется транспонировать. Как матрицу :).
> Экзотическая, надо сказать, задача. А зачем это, если не
> секрет?

Да правильно транспонировать, ошибся я.
Дело в том что данные о платежах храняться в таблице построчно (т.е. одна квитанция занимает от 4х строк: фамилия, л/с, сумма ....) у каждого элемента свой номер фамилия -16, сумма-1, л/с - 32 ........ на каждую организацию кол-во элементов разное поэтому ради универсальности приложения сделано такое хранение данных. Так вот мне нужно по заранее известной схеме (для каждой организации своя) перевернуть эти данные в нормальную форму (т.е. чтобы элементы были столбцами) и чтобы получился в итоге нормальный понятный список.

Desdechado (2006-08-03 16:05:00) [16]
Dok (03.08.06 15:58) [25]
Похоже, ты из Одессы. Поганая привычка - отвечать вопросом на вопрос.

> а для тебя есть разница сервер азы данных и сервер приложения?
Читаешь по диагонали? С тобой все ясно. Я все сказал, еще в [17].
Повторять смысла не вижу.

Dok (2006-08-03 15:58:00) [17]

> Приложение и сервер приложений для тебя разницу имеют?

так же как килограмм и метр, а что?

> Если да, тогда зачем жонглируешь терминами?

а для тебя есть разница сервер азы данных и сервер приложения?

Desdechado (2006-08-03 15:39:00) [18]
> но никак этим не приложение занимается
Приложение и сервер приложений для тебя разницу имеют?
Если нет, то с тобой все ясно. Если да, тогда зачем жонглируешь терминами?

Dok (2006-08-03 14:54:00) [19]

> ОЛАП и расчитывает, но, насколько я знаю, данные в нем лежат
> не так, как в "боевом" сервере, а "несколько" иначе - более
> денормализовано для скорости расчетов. Так что это уже получается
> некий симбиоз сервера БД и приложений.
>

По разному есть и расчитанные данные лежат. есть и динамические данные, но никак этим не приложение занимается,а ХП и запросы.

> Кстати, не думаю, что ОЛАП - это то чем занимается автор
> топика.

Мне тоже так кажется :) Но думаю после этой дискуссии у афтора прояснится что он хотел.

Sergey13 (2006-08-03 14:28:00) [20]
Кстати, не думаю, что ОЛАП - это то чем занимается автор топика.

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »