dmidek Выбегалло




это на каком диалекте ? Ни Informix, ни Sybase IQ не понимают "select over", "partition by".
Нельзя ли ограничиться стандартом ?

И нахрена там decode ?

dmidek Выбегалло dmidek Выбегалло




это на каком диалекте ? Ни Informix, ни Sybase IQ не понимают "select over", "partition by".
Нельзя ли ограничиться стандартом ?

И нахрена там decode ?

Это Oracle. Аналитические функции. Доступны с 8i

В каком смысле "на хрена" ?

Вот FAQ: Транспонирование строк в стобцы

Банальные вещи ...

Ну вы таки попробуйте без извратов, на чистом SQL. Чтобы типа переносимо было.

Bogdanov Andrey БредА я просто сравниваю, потому что раздел так называется. Я тоже не ругаю и не хвалю, а привожу результат. Еще раз: у этих колонок могут быть свои ограничения целостности, имена (смысл). Именно Ваш способ и делает тест бессмысленным. Результат Oracle: 1.11 Гб. Я его не ругаю, и не хвалю.
Мне как раз кажется, что ваше сравнение совершенно бессмысленно. Вы взяли некий объект в Oracle и некий объект в Cache почему-то решили, что это однородные объекты и решили сравнить их размер. С таким же успехом можно сказать, что у Эйфелевой башни 300 метров, а у великой китайской стены - 6 миллионов метров (могу ошибиться с цифрами). Это сравнение ни о чем. Вот если вы возьмете некую приклдадную задачу, то можно сравнивать ее реализации.
Вы можете сказать, что взяли вот задачу хранения разреженных массивов (осталось только строго формализовать ее) и сравнили. Но заметим, что при этом вы сравнили не СУБД, а две ВАШИХ реализации этой задачи. Как только я предложил другую реализацию вы начали навешивать дополнительные требования и ограничения.

Ну дело таки в том, что реализация "разряженных массивов" в Oracle таки хромает. Занимается масса дискового пространства, которое никак не используется. Хуже того - при выборке приходится все это пустое место считывать с диска и кидать в память, при записи - сливать на диск. Имеете что возразить ?
При прочих равных, СУБД с более компактным хранением данных имеет преимущество в скорости выполнения запросов. Не говоря уже о стоимости дисков.
Проблема коллеги ЧАЛа в том, что он свято убежден в порочности реляционной ИДЕИ. Вот тут-то Sybase IQ и вставляет ему перо в ж... в одно место. Оказывается, можно хранить "разряженные массивы" экономно - и при этом оставаться реляционной СУБД. Все зависит от внутренней реализации.

dmidek
Это Oracle. Аналитические функции. Доступны с 8i

В каком смысле "на хрена" ?

Вот FAQ: Транспонирование строк в стобцы

Банальные вещи ...

Специалист в Оракле подобен флюсу: полнота его односторонняя. (С)
Попробуйте для расширения кругозора попереносить эти "вещи" на Informix, DB2 или Sybase. Я вас уверяю, ваша склонность пользоваться "банальными вещами" резко уменьшится.

dmidek Выбегалло
Ну вы таки попробуйте без извратов, на чистом SQL. Чтобы типа переносимо было.

Хорошо, тогда эмулируем row_number с помощью rownum




Вы техзадания тоже как понимаете ? Или просто незнакомы со стандартом ?
Повторяю задачу : написать SQL понимаемый большинством СУБД. Это значит, не надо использовать DECODE, ROWNUM, и MOD тоже нежелателен (без него вполне можно обойтись). Так уж и быть, SELECT from (SELECT) достаточно легко эмулировать.

drev Выбегалло Bogdanov Andrey ВыбегаллоА нарисуйте мне SELECT A,B,C from table1 WHERE id = 1 and datastamp = '2007-07-26' ?
У меня заняло 30 секунд запрос напечатать - сколько у вас займет ?

Итого секунд 25. Ну а вообще, никто не мешает сделать view.

ВыбегаллоИ, кстати, вы как собираетесь char-ы с int-ами хранить - кошерно, в отдельных таблицах, или все в varchar-ы преобразовывать будете ?
В условиях тестовой задачи было четко сказано "значения типа int". А в реальной жизни я буду выбирать способ хранения наиболее адекватный задаче.

Вы, Андрей, извиняюсь, написали за 25 секунд полную фигню. Начнем с того, что вы попутали RecordID (аналог Row ID, внутренняя переменная) с колонкой ID. Что собственно доказывает мой пойнт - для работы с такими структурами надо иметь немало серого вещества в голове и свободного времени на руках.

Вот вам тестовый пример, и попробуйте таки написать SELECT, возвращающий ПРАВИЛЬНЫЕ значения.
Дано :
"Просто" таблица
declare LOCAL TEMPORARY TABLE RealTable(
a int,
b int,
c int,
ID int) on commit preserve rows;

Засовываем в нее 3 записи :
insert into RealTable (a,b,c, ID) values (11, 21, 31, 1);
insert into RealTable (a,b,c, ID) values (12, 22, 32, 1);
insert into RealTable (a,b,c, ID) values (13, 23, 33, 2);

Пишем селект:
select a, b, c from RealTable where id = 1;
Результат :
a,b,c
11,21,31
12,22,32

Теперь переводим все это в "удобную плоскую форму" :
declare LOCAL TEMPORARY TABLE EmptyTable(
recordID int,
colId int,
colValue int) on commit preserve rows;

/* record 1 */
insert into EmptyTable(RecordId,ColId,ColValue)
values (1, 1, 11);

insert into EmptyTable(RecordId,ColId,ColValue)
values (1, 2, 21);

insert into EmptyTable(RecordId,ColId,ColValue)
values (1, 3, 31);

insert into EmptyTable(RecordId,ColId,ColValue)
values (1, 4, 1);

/* record 2 */
insert into EmptyTable(RecordId,ColId,ColValue)
values (2, 1, 12);

insert into EmptyTable(RecordId,ColId,ColValue)
values (2, 2, 22);

insert into EmptyTable(RecordId,ColId,ColValue)
values (2, 3, 32);

insert into EmptyTable(RecordId,ColId,ColValue)
values (2, 4, 1);

/* record 3 */
insert into EmptyTable(RecordId,ColId,ColValue)
values (3, 1, 12);

insert into EmptyTable(RecordId,ColId,ColValue)
values (3, 2, 22);

insert into EmptyTable(RecordId,ColId,ColValue)
values (3, 3, 32);

insert into EmptyTable(RecordId,ColId,ColValue)
values (3, 4, 2);

Ваш SELECT :
select ColValue A, ColValue B, ColValue C
from EmptyTable where RecordId = 1;

Результаты :
A,B,C
11,11,11
21,21,21
31,31,31
1,1,1

Ну полная фигня, верно ?

Результаты drev (идея получше), но все равно фигня получается :

select max(A), max(B), max(C)
from
(
select ColValue A, ColValue B, ColValue C, RecordId
from emptyTable a
where exists
( select 1 from EmptyTable b where b.RecordId = a.RecordId and b.ColId = 4 and b.ColValue = 1)

) tmpr
group by RecordId

max(a.ColValue as A), max(a.ColValue as B), max(a.ColValue as C)
31,31,31
32,32,32


В общем, думайте еще.


Вы упростили мой селект:) если вы вернете decode, то получите ровно правильный результат:)


К сожалению, мне не на чем ваш правильный результат проверить. Попробуйте написать SELECT для не-ораклистов.

drevПоверьте на слово. Или напишите функцию на Вашем диалекте, которая принимает три параметра.

Если первый равен второму - вернуть третий, иначе - null.

Кстати, на мой вгляд, идея "писать на стандарте" порочна в 99% случаев.

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

drev Выбегалло drevПоверьте на слово. Или напишите функцию на Вашем диалекте, которая принимает три параметра.

Если первый равен второму - вернуть третий, иначе - null.

Кстати, на мой вгляд, идея "писать на стандарте" порочна в 99% случаев.

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


1. "наезжать" не стоит:) меняйте тон:)

2. вызов детерминисткой UDF в селект листе разрешен стандартом :)

3. я не-ораклист :) на SQL Server, например, я бы написал через case:)

Case нынче практически все понимают, так что case Ok. Допустим, выродится все это в изврат типа
create view emptyview as
select max(A) A, max(B) B, max(C) C, max(ID) ID
from
(
select
case when ColId =1 THEN ColValue ELSE null END A,
case when ColId =2 then ColValue ELSE null END B,
case when ColId =3 then ColValue ELSE null END C,
case when ColId =4 then ColValue ELSE null END ID,
RecordId
from emptytable a
) tmpr
group by RecordId

Заметьте, что данный результат получен к концу второго дня. Мы пришли к View, который позволяет вернуться к простоте классического селекта. Можно, конечно, оставить все как есть (без view), понадеявшись, что бизнес-юзера умственными способностями уж не слабже Андрея Богданова будут (который сходу нашел очевидное и легкое для понимания неправильное решение) - но я бы не рискнул. Они (юзера) могут и причиндалы оторвать за подобное.

Но что вы с индексами будете делать ? select * from emptyview where A = 1 - ему же не один индекс даже теоретически не поможет, придется всю таблицу каждый раз перечитывать. А допустим у вас пара миллиардов записей в обычной таблице, да колонок в ней 100-150 (ну любят аналитики такие схемы) - и сколько строк у вас получится ?

drev Выбегалло

Кстати, оффтопик, просто интересно. Я понимаю, Аризона, с ИТ проблемы.. Но Вам не надоело работать с "мёртвой" СУБД?

С какой из трех ? IQ, Informix или DB2 ?
Слухи о смерти любой из них несколько преувеличены.
И потом, смквельсерверщиков вокруг - плюнуть некуда, ораклистов как собак, а информиксоиды - люди редкие, дорогие... :-)

drev Выбегалло drev Выбегалло

Кстати, оффтопик, просто интересно. Я понимаю, Аризона, с ИТ проблемы.. Но Вам не надоело работать с "мёртвой" СУБД?

С какой из трех ? IQ, Informix или DB2 ?
Слухи о смерти любой из них несколько преувеличены.
И потом, смквельсерверщиков вокруг - плюнуть некуда, ораклистов как собак, а информиксоиды - люди редкие, дорогие... :-)

С первых двух:)

Не знаю, нишевый маркет..опасно..

11 лет - полет нормальный. Зато практически нет индусов, рождающихся со знанием Informix. А вот на Transact SQL, судя по их резюме, им мама колыбельные пела :-)

drev Выбегалло
Case нынче практически все понимают, так что case Ok. Допустим, выродится все это в изврат типа
create view emptyview as
select max(A) A, max(B) B, max(C) C, max(ID) ID
from
(
select
case when ColId =1 THEN ColValue ELSE null END A,
case when ColId =2 then ColValue ELSE null END B,
case when ColId =3 then ColValue ELSE null END C,
case when ColId =4 then ColValue ELSE null END ID,
RecordId
from emptytable a
) tmpr
group by RecordId

Заметьте, что данный результат получен к концу второго дня. Мы пришли к View, который позволяет вернуться к простоте классического селекта. Можно, конечно, оставить все как есть (без view), понадеявшись, что бизнес-юзера умственными способностями уж не слабже Андрея Богданова будут (который сходу нашел очевидное и легкое для понимания неправильное решение) - но я бы не рискнул. Они (юзера) могут и причиндалы оторвать за подобное.

Но что вы с индексами будете делать ? select * from emptyview where A = 1 - ему же не один индекс даже теоретически не поможет, придется всю таблицу каждый раз перечитывать. А допустим у вас пара миллиардов записей в обычной таблице, да колонок в ней 100-150 (ну любят аналитики такие схемы) - и сколько строк у вас получится ?


Кстати, селект Вы опять поломали:)

Нибожемой. Перевел в case как Вы сказали.

dmidek

У Выбегалло трудности в приведении к стандартам SQL :-)


У меня ? Да я тут единственный, кто ваши оракловские расширения переводит на нормальный язык.
Вы себя что-то пока никак не проявили.

dmidek
2Выбегалло :

На случай, если Вы еще не разобрались в моих вариантах,
скажу, что они являются более общим случаем рассмотренного ,
а именно работают и в том случае, когда colid не представляет собой
непрерывную числовую последовательность от 1 до 4, а имеет
четыре любых дискретных значения

Кстати, как бы выглядел вариант на "стандартном" SQL, в котором colid
расположены не непрерывно, а с дырками, ну скажем на таком примере

То есть завязываться на конкретные значения colid нельзя -
они могут быть любыми.
Продемонстрируйте, если не трудно.
Хочется насладиться мощью стандартных решений :-)

По-моему, у вас склероз. Это я просил изобразить селект на СТАНДАРТНОМ SQL. И даже продемонстрировал пример с CASE. Вы себя на поприще умения работать со стандартом пока никак не проявили, так что сейчас как раз подходящий момент показать крутизну.
А ваш "общий случай" не работает хотя бы потому, что вы не возвращаете четвертую колонку (ID ) - соответственно фильтр накладывать не на что.
И относительно вашего замечания про привязывания к конкретным colid - вам при SELECTе имена колонок требуются ? Ну так в "плоской форме" их заменяют colid. Отфонаря их брать нельзя, фигня получится. Что является еще одним недостатком данной модели.