ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Разработка СУБД
25 сообщений из 195, страница 7 из 8
  7  все
Разработка СУБД
    #34690977
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dmidek
Участник
Выбегалло dmidek

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


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


Ну посмотрим Ваш перевод.

Выбегалло Bogdanov Andrey ВыбегаллоА нарисуйте мне SELECT A,B,C from table1 WHERE id = 1 and datastamp = '2007-07-26' ?
У меня заняло 30 секунд запрос напечатать - сколько у вас займет ?
Код: plaintext
1.
select decode(ColId, 1 ,ColValue,null) A, decode(ColId, 2 ,ColValue,null) B, decode(ColId, 3 ,ColValue,null) C
from table1 where RecordId =  1 ;

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

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

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

Ваш 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

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



Смотрите , Выбегалло, что Вы делаете.
Берете селект Андрея, обзываете его полной фигней , а затем переводите.
Перевод заключатеся в том, что Вы выбрасываете DECODE и оставляете только
третий параметр

Код: plaintext
decode(ColId, 1 ,ColValue,null) A -> ColValue

Такой метод перевода хорошо известен. Начинающему говорят "Выбрасывайте все незнакомые
слова, оставляйте только то, что знаете". К сожалению, здесь такой прием не работает
и показывает только Вашу вопиющую безграмотность, которая вкупе с апломбом
производит совершенно удручающее впечатление. Не позорьтесь, скажите прямо
"Я не знаю , что значит DECODE"
И ВЫ еще меня спрашивали "А на фига здесь DECODE ?"
Я подумал "Глубоко копает" А выясняется, да Вы просто не знаете.

Теперь посмотрим Ваш другой опус.

ВыбегаллоРезультаты 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 выброшен на свалку истории.
Фигня конечно, которую Вы и произвели на свет Божий.

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


Ха-ха-ха, что значит "не работает" ?
Вы результат видели ? Он получен в Oracle.
Для фильтрации по определенному полю, его не надо указывать в select- списке
Если мне понадобится представление, о котором я ничего не говорил,
я добавлю ,col4 в результипующий SELECT. Это надеюсь понятно ?

Выбегалло, Вы лучше философствуйте. Не надо опускаться до уровня кода.
А то уж больно смешно выглядит.

P.S. Как там мой примерчик ?
...
Рейтинг: 0 / 0
29.07.2007, 11:19
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34691304
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
Вот drev - он повыделывался с decode, а потом взял и перевел в стандартные joinы . Типа могет человек. А вы только языком трепать горазды.
...
Рейтинг: 0 / 0
29.07.2007, 21:24
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34691309
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
dmidek Выбегалло dmidek

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


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


Ну посмотрим Ваш перевод.

Выбегалло Bogdanov Andrey ВыбегаллоА нарисуйте мне SELECT A,B,C from table1 WHERE id = 1 and datastamp = '2007-07-26' ?
У меня заняло 30 секунд запрос напечатать - сколько у вас займет ?
Код: plaintext
1.
select decode(ColId, 1 ,ColValue,null) A, decode(ColId, 2 ,ColValue,null) B, decode(ColId, 3 ,ColValue,null) C
from table1 where RecordId =  1 ;

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

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

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

Ваш 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

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



Смотрите , Выбегалло, что Вы делаете.
Берете селект Андрея, обзываете его полной фигней , а затем переводите.
Перевод заключатеся в том, что Вы выбрасываете DECODE и оставляете только
третий параметр

Код: plaintext
decode(ColId, 1 ,ColValue,null) A -> ColValue

Такой метод перевода хорошо известен. Начинающему говорят "Выбрасывайте все незнакомые
слова, оставляйте только то, что знаете". К сожалению, здесь такой прием не работает
и показывает только Вашу вопиющую безграмотность, которая вкупе с апломбом
производит совершенно удручающее впечатление. Не позорьтесь, скажите прямо
"Я не знаю , что значит DECODE"



Мне как-то глубоко покласть на ваше мнение о моей (без)грамотности, удивляет только, с какого перепугу вы решили, что оракловские расширения должны быть известны разработчикам других платформ.
А select Андрея - он что без decode, что с decode - работать не будет.
...
Рейтинг: 0 / 0
29.07.2007, 21:30
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34691333
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dmidek
Участник
ВыбегаллоВот drev - он повыделывался с decode, а потом взял и перевел в стандартные joinы . Типа могет человек.

drev допустил маленькую ошибочку. Надо так

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
select A, B, C, ID
from 
(
	select 
		t1.ColValue A,
		t2.ColValue B,
		t3.ColValue C,
		t4.ColValue ID
	from
	
	emptytable t1 
		inner join
	emptytable t2 	on t1.RecordId = t2.RecordId and t1.ColId =  1  and t2.ColId =  2 
		inner join
	emptytable t3 	on t1.RecordId = t3.RecordId and t3.ColId =  3  
		inner join
	emptytable t4 	on t1.RecordId = t4.RecordId and t4.ColId =  4 
)
where ID =  1 ;

ИМХО это overkill и первый вариант в 100 раз лучше...
...
Рейтинг: 0 / 0
29.07.2007, 22:04
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34691343
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
dmidek ВыбегаллоВот drev - он повыделывался с decode, а потом взял и перевел в стандартные joinы . Типа могет человек.

drev допустил маленькую ошибочку. Надо так

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
select A, B, C, ID
from 
(
	select 
		t1.ColValue A,
		t2.ColValue B,
		t3.ColValue C,
		t4.ColValue ID
	from
	
	emptytable t1 
		inner join
	emptytable t2 	on t1.RecordId = t2.RecordId and t1.ColId =  1  and t2.ColId =  2 
		inner join
	emptytable t3 	on t1.RecordId = t3.RecordId and t3.ColId =  3  
		inner join
	emptytable t4 	on t1.RecordId = t4.RecordId and t4.ColId =  4 
)
where ID =  1 ;

ИМХО это overkill и первый вариант в 100 раз лучше...


А в каких диалектах нужно обязательно указывать ID в селект-листе, чтобы использовать в WHERE? Я так навскидку не помню.

Да, оверкилл, но схема легче расширяется, если у нас колонки разных типов и для хранения используются несколько таблиц: для int, float, varchar, etc.
...
Рейтинг: 0 / 0
29.07.2007, 22:18
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34691347
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dmidek
Участник
Выбегалло
Мне как-то глубоко покласть на ваше мнение о моей (без)грамотности, удивляет только, с какого перепугу вы решили, что оракловские расширения должны быть известны разработчикам других платформ.


Да дело же совсем не в этом. Я вот совершенный ноль и в Sybase и в Informix,
и в чем только нет, но это же не повод проводить вивисекцию кода и озвучивать
неверные результаты ...
Впрочем, это не оправдывает мой резкий тон.
Извините пожалуйста, был в "реальном" очень дурном настроении :-(

Выбегалло
А select Андрея - он что без decode, что с decode - работать не будет.

Здесь Вы правы, он нуждается в легкой доработке напильничком.
В одном случае получится вариант drev,
вот у меня еще такой симпатичный получился ...

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select 
max(decode(ColId, 1 ,ColValue,null)) A, 
max(decode(ColId, 2 ,ColValue,null)) B, 
max(decode(ColId, 3 ,ColValue,null)) C,
max(decode(ColId, 4 ,ColValue,null)) ID
from emptytable
group by recordid 
having max(decode(ColId, 4 ,ColValue,null)) =  1 
/
A B C ID 
 11   21   31   1  
 12   22   32   1
...
Рейтинг: 0 / 0
29.07.2007, 22:28
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34691350
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dmidek
Участник
drev dmidek ВыбегаллоВот drev - он повыделывался с decode, а потом взял и перевел в стандартные joinы . Типа могет человек.

drev допустил маленькую ошибочку. Надо так

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
select A, B, C, ID
from 
(
	select 
		t1.ColValue A,
		t2.ColValue B,
		t3.ColValue C,
		t4.ColValue ID
	from
	
	emptytable t1 
		inner join
	emptytable t2 	on t1.RecordId = t2.RecordId and t1.ColId =  1  and t2.ColId =  2 
		inner join
	emptytable t3 	on t1.RecordId = t3.RecordId and t3.ColId =  3  
		inner join
	emptytable t4 	on t1.RecordId = t4.RecordId and t4.ColId =  4 
)
where ID =  1 ;

ИМХО это overkill и первый вариант в 100 раз лучше...


А в каких диалектах нужно обязательно указывать ID в селект-листе, чтобы использовать в WHERE? Я так навскидку не помню.

Да, оверкилл, но схема легче расширяется, если у нас колонки разных типов и для хранения используются несколько таблиц: для int, float, varchar, etc.

Дело вовсе не в этом, у Вас была описка

select
t1.ColValue A,
t1.ColValue B,
t1.ColValue C,
t1.ColValue ID
...
Рейтинг: 0 / 0
29.07.2007, 22:32
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34691353
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
dmidek Дело вовсе не в этом, у Вас была описка

select
t1.ColValue A,
t1.ColValue B,
t1.ColValue C,
t1.ColValue ID


aaa ))))))
...
Рейтинг: 0 / 0
29.07.2007, 22:37
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34691620
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
ВыбегаллоВы техзадания тоже как понимаете ? Или просто незнакомы со стандартом ?
Повторяю задачу : написать SQL понимаемый большинством СУБД. Это значит, не надо использовать DECODE, ROWNUM, и MOD тоже нежелателен (без него вполне можно обойтись). Так уж и быть, SELECT from (SELECT) достаточно легко эмулировать.
Слава богу, что не вы мне техзадания выдаете. Я приводил пример хранения разреженных массивов в ORACLE. Вас этот пример не устроил тем, что в не смогли перенести его на другие СУБД. Извините, но это идиотизм. Мы либо обсуждаем реализацию разреженных массивов на Oracle, либо на других СУБД. По-поводу Oracle я все сказал, а про другие СУБД ничего говорить не хочу.
...
Рейтинг: 0 / 0
30.07.2007, 09:34
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34691815
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
Bogdanov Andrey ВыбегаллоВы техзадания тоже как понимаете ? Или просто незнакомы со стандартом ?
Повторяю задачу : написать SQL понимаемый большинством СУБД. Это значит, не надо использовать DECODE, ROWNUM, и MOD тоже нежелателен (без него вполне можно обойтись). Так уж и быть, SELECT from (SELECT) достаточно легко эмулировать.
Слава богу, что не вы мне техзадания выдаете. Я приводил пример хранения разреженных массивов в ORACLE. Вас этот пример не устроил тем, что в не смогли перенести его на другие СУБД. Извините, но это идиотизм. Мы либо обсуждаем реализацию разреженных массивов на Oracle, либо на других СУБД. По-поводу Oracle я все сказал, а про другие СУБД ничего говорить не хочу.

ничего специфически ораклового в задаче нет, и решается она вполне замечательно средствами стандартного SQL , причем двумя вариантами - с JOIN и с GROUP BY. Не знаю что лично вы обсуждали, а я обсуждал недостатки данной модели, которые на всех СУБД одинаковы - непрозрачность запросов для разработчиков и для оптимизатора. Первую проблему вы прекрасно проиллюстрировали на собственном примере. И это в самом упрощенном варианте. Вы попробуйте написать селект, использующий разные типы данных.
...
Рейтинг: 0 / 0
30.07.2007, 10:43
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34691980
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Выбегаллоничего специфически ораклового в задаче нет, и решается она вполне замечательно средствами стандартного SQL , причем двумя вариантами - с JOIN и с GROUP BY. Не знаю что лично вы обсуждали, а я обсуждал недостатки данной модели, которые на всех СУБД одинаковы - непрозрачность запросов для разработчиков и для оптимизатора. Первую проблему вы прекрасно проиллюстрировали на собственном примере. И это в самом упрощенном варианте. Вы попробуйте написать селект, использующий разные типы данных.
Не знаю о каких модели вы говорите. Бред в качестве недостатков реляционных СУБД (точнее в качестве примущества cache над реляционными СУБД) назвал неумение ими компактно хранить разреженные массивы. И предложил некий тест, который по его мнению, показывал это неумение. Я своим примером показал, что вопрос компактного хранения - это исключительно вопрос умения спроектировать базу данных. И на oracle "бредовский тест" может быть реализован ровно с теми же параметрами по занимаемому объему, что и на cache.
Вы же почему-то в ответ на это решили обсуждать недостатки какой-то там модели. И при этом, по-всей видимости, занесли меня в сторонники этой самой модели. Давайте отделим мух от котлет. Если вам интересно обсуждать некую модель - пожалуйста, но вряд ли я буду вашим оппонентом.
...
Рейтинг: 0 / 0
30.07.2007, 11:23
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34692043
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dmidek
Участник
Выбегалло Вы попробуйте написать селект, использующий разные типы данных.

Но проблема же здесь в этом случае не в селекте, а в выборе
изначально неверного типа для ColValue. Он должен быть в нашем случае
символьный - VARCHAR2 и тогда мы делаем запрос с помощью преобразования типов.
Я изменил тип колонки ColValue на VARCHAR2(100), дополнил Ваш пример
следующими тестовыми данными

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
insert  into emptytable 
 values ( 1 , 5 ,'2007-07-26')
/
insert  into emptytable 
values ( 2 , 5 ,'2007-05-26')
/
insert  into emptytable 
values ( 3 , 5 ,'2006-04-26')
/
insert  into emptytable 
values ( 1 , 6 ,'MASHA')
/
insert  into emptytable 
values ( 2 , 6 ,'VASJA')
/
insert  into emptytable 
values ( 3 , 6 ,'PETJA')
/

и вот

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SQL> select max(decode(ColId,  1 , ColValue, null)) A,
   2          max(decode(ColId,  2 , ColValue, null)) B,
   3          max(decode(ColId,  3 , ColValue, null)) C,
   4          max(decode(ColId,  4 , ColValue, null)) ID,
   5          max(decode(ColId,  5 , ColValue, null)) Datum,
   6          max(decode(ColId,  6 , ColValue, null)) Text
   7     from emptytable
   8    group by recordid
   9   having max(decode(ColId,  4 , ColValue, null)) = '1'
  10   and max(decode(ColId,  5 , to_date(ColValue, 'YYYY-MM-DD'), null))
  11       = to_date('2007-05-26', 'YYYY-MM-DD')
  12   and max(decode(ColId,  6 , ColValue)) = 'VASJA'
  13   /
 
A          B          C          ID         DATUM      TEXT
---------- ---------- ---------- ---------- ---------- ----------
 12           22           32           1            2007 - 05 - 26  VASJA
 
SQL>

TO_DATE сделано только для демонстрации явного преобразования типов.
В случае можно конечно проверять дату просто как строку ...
...
Рейтинг: 0 / 0
30.07.2007, 11:35
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34693605
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer БредТолько как-то грустно, что даже не стремитесь к пониманию предмета Вашего труда.
Здравствуйте, Андрей Леонидович.

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

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

Пусть чал летит себе с Вашим пером в ж...
Но если реляционные ИДЕЯ (С) порочна, то как ее может спасти "экономное хранение разреженных массивов" ??? Кстати, перечитал высказавания чала (ну может не все), и не нашел ничего про "разреженные массивы", которые невозможно реализовать в рамках "реляционной идеи". После Ваших пламенных и весьма нервных выступлений я уже начал подумывать о том, что не все в порядке с реляционной ИДЕЕЙ (С).
...
Рейтинг: 0 / 0
30.07.2007, 17:37
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34693691
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
Выбегалло
Мне как-то глубоко покласть на ваше мнение о моей (без)грамотности, удивляет только, с какого перепугу вы решили, что оракловские расширения должны быть известны разработчикам других платформ.

зашибись позиция, давайте теперь всех заставим ориентироватся на субд которые сумарно занимают 2% рынка :) аналитические функции прописаны в стандарте ANSI SQL и поддерживаются любой нормальной субд.
...
Рейтинг: 0 / 0
30.07.2007, 17:46
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34693694
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Bogdanov Andrey Выбегаллоничего специфически ораклового в задаче нет, и решается она вполне замечательно средствами стандартного SQL , причем двумя вариантами - с JOIN и с GROUP BY. Не знаю что лично вы обсуждали, а я обсуждал недостатки данной модели, которые на всех СУБД одинаковы - непрозрачность запросов для разработчиков и для оптимизатора. Первую проблему вы прекрасно проиллюстрировали на собственном примере. И это в самом упрощенном варианте. Вы попробуйте написать селект, использующий разные типы данных.
Не знаю о каких модели вы говорите. Бред в качестве недостатков реляционных СУБД (точнее в качестве примущества cache над реляционными СУБД) назвал неумение ими компактно хранить разреженные массивы. И предложил некий тест, который по его мнению, показывал это неумение. Я своим примером показал, что вопрос компактного хранения - это исключительно вопрос умения спроектировать базу данных. И на oracle "бредовский тест" может быть реализован ровно с теми же параметрами по занимаемому объему, что и на cache.
Вы же почему-то в ответ на это решили обсуждать недостатки какой-то там модели. И при этом, по-всей видимости, занесли меня в сторонники этой самой модели. Давайте отделим мух от котлет. Если вам интересно обсуждать некую модель - пожалуйста, но вряд ли я буду вашим оппонентом.

Не вводите людей в заблуждение. "Бредовский тест" на Oracle дает 1.11 Гб. Поэтому, наверное, Вы заменили его собственным тестом, умышленно изменив логическую модель. Вы использовали модель, о которой я сказал еще до Вашего сообщения, и которую можно иногда ВЫНУЖДЕННО использовать, получая очень неудобную для прямых запросов структуру. Хотя бы привели пример, когда структуру из Вашего теста УДОБНО И ПРАВИЛЬНО использовать, заменяя ей нормальную структуру данных.
...
Рейтинг: 0 / 0
30.07.2007, 17:47
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34693774
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
SergSuper pavelvp Если Вы напряжёте свою память, Андрей Леонидович, то наверняка вспомните...
ЧАЛ из Латвии писал, а этот IP московский
Да и стилистика немного другая. Я всё-таки склоняюсь что не онпростите меня люди, был не прав, всё-таки это он
...
Рейтинг: 0 / 0
30.07.2007, 18:10
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34693906
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
SergSuper пишет:
> ЧАЛ из Латвии писал, а этот IP московский
> Да и стилистика немного другая. Я всё-таки склоняюсь что не он
>
> простите меня люди, был не прав, всё-таки это он

Дайте пож. ссылку на Чала. На настоящего.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
30.07.2007, 18:43
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34693954
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, SergSuper!
Ты пишешь:

SergSuperS> простите меня люди, был не прав, всё-таки это оноб чем я и говорил...

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
30.07.2007, 19:01
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34693977
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
Yo.! Выбегалло
Мне как-то глубоко покласть на ваше мнение о моей (без)грамотности, удивляет только, с какого перепугу вы решили, что оракловские расширения должны быть известны разработчикам других платформ.

зашибись позиция, давайте теперь всех заставим ориентироватся на субд которые сумарно занимают 2% рынка :) аналитические функции прописаны в стандарте ANSI SQL и поддерживаются любой нормальной субд.

Да вы наперсточник, батенька.
1. DECODE - в стандарте не прописано.
2. Oracle не занимает 98% рынка.
3. С какой стати DECODE должно быть известно разработчикам других платформ ?
...
Рейтинг: 0 / 0
30.07.2007, 19:09
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34693978
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
MasterZiv
SergSuper пишет:
> ЧАЛ из Латвии писал, а этот IP московский
> Да и стилистика немного другая. Я всё-таки склоняюсь что не он
>
> простите меня люди, был не прав, всё-таки это он

Дайте пож. ссылку на Чала. На настоящего.
Posted via ActualForum NNTP Server 1.4

Вот тут вот самый классический ЧАЛ, тема почти умирала и 14-й странице он появляется

вот тут еще есть ( но сначала всё по первой ссылке прочитайте )
...
Рейтинг: 0 / 0
30.07.2007, 19:09
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34693996
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
dmidek Выбегалло Вы попробуйте написать селект, использующий разные типы данных.

Но проблема же здесь в этом случае не в селекте, а в выборе
изначально неверного типа для ColValue. Он должен быть в нашем случае
символьный - VARCHAR2 и тогда мы делаем запрос с помощью преобразования типов.
Я изменил тип колонки ColValue на VARCHAR2(100), дополнил Ваш пример
следующими тестовыми данными

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
insert  into emptytable 
 values ( 1 , 5 ,'2007-07-26')
/
insert  into emptytable 
values ( 2 , 5 ,'2007-05-26')
/
insert  into emptytable 
values ( 3 , 5 ,'2006-04-26')
/
insert  into emptytable 
values ( 1 , 6 ,'MASHA')
/
insert  into emptytable 
values ( 2 , 6 ,'VASJA')
/
insert  into emptytable 
values ( 3 , 6 ,'PETJA')
/

и вот

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SQL> select max(decode(ColId,  1 , ColValue, null)) A,
   2          max(decode(ColId,  2 , ColValue, null)) B,
   3          max(decode(ColId,  3 , ColValue, null)) C,
   4          max(decode(ColId,  4 , ColValue, null)) ID,
   5          max(decode(ColId,  5 , ColValue, null)) Datum,
   6          max(decode(ColId,  6 , ColValue, null)) Text
   7     from emptytable
   8    group by recordid
   9   having max(decode(ColId,  4 , ColValue, null)) = '1'
  10   and max(decode(ColId,  5 , to_date(ColValue, 'YYYY-MM-DD'), null))
  11       = to_date('2007-05-26', 'YYYY-MM-DD')
  12   and max(decode(ColId,  6 , ColValue)) = 'VASJA'
  13   /
 
A          B          C          ID         DATUM      TEXT
---------- ---------- ---------- ---------- ---------- ----------
 12           22           32           1            2007 - 05 - 26  VASJA
 
SQL>

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


Мало того, что разработчик вместо имен колонок должен использовать их номера - так ему еще и помнить их типы требуется.
Зашибись простота.
Кстати, подумал я про сворачивание этого всего полета архитекторной мысли во view для нормального использования - тоже проблемы видны. Много дурной работы серверу придется делать, если в таблице, скажем, 30 колонок, а интересуют всего 2-3-5.
...
Рейтинг: 0 / 0
30.07.2007, 19:18
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34694013
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dmidek
Участник
Выбегалло dmidek Выбегалло Вы попробуйте написать селект, использующий разные типы данных.

Но проблема же здесь в этом случае не в селекте, а в выборе
изначально неверного типа для ColValue. Он должен быть в нашем случае
символьный - VARCHAR2 и тогда мы делаем запрос с помощью преобразования типов.
Я изменил тип колонки ColValue на VARCHAR2(100), дополнил Ваш пример
следующими тестовыми данными

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
insert  into emptytable 
 values ( 1 , 5 ,'2007-07-26')
/
insert  into emptytable 
values ( 2 , 5 ,'2007-05-26')
/
insert  into emptytable 
values ( 3 , 5 ,'2006-04-26')
/
insert  into emptytable 
values ( 1 , 6 ,'MASHA')
/
insert  into emptytable 
values ( 2 , 6 ,'VASJA')
/
insert  into emptytable 
values ( 3 , 6 ,'PETJA')
/

и вот

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SQL> select max(decode(ColId,  1 , ColValue, null)) A,
   2          max(decode(ColId,  2 , ColValue, null)) B,
   3          max(decode(ColId,  3 , ColValue, null)) C,
   4          max(decode(ColId,  4 , ColValue, null)) ID,
   5          max(decode(ColId,  5 , ColValue, null)) Datum,
   6          max(decode(ColId,  6 , ColValue, null)) Text
   7     from emptytable
   8    group by recordid
   9   having max(decode(ColId,  4 , ColValue, null)) = '1'
  10   and max(decode(ColId,  5 , to_date(ColValue, 'YYYY-MM-DD'), null))
  11       = to_date('2007-05-26', 'YYYY-MM-DD')
  12   and max(decode(ColId,  6 , ColValue)) = 'VASJA'
  13   /
 
A          B          C          ID         DATUM      TEXT
---------- ---------- ---------- ---------- ---------- ----------
 12           22           32           1            2007 - 05 - 26  VASJA
 
SQL>

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


Мало того, что разработчик вместо имен колонок должен использовать их номера - так ему еще и помнить их типы требуется.
Зашибись простота.
Кстати, подумал я про сворачивание этого всего полета архитекторной мысли во view для нормального использования - тоже проблемы видны. Много дурной работы серверу придется делать, если в таблице, скажем, 30 колонок, а интересуют всего 2-3-5.

Почему он должен помнить номера ?
Мы можем если хотим ввести колонку ColName и работать с ней точно так же вместо ColId.

Вы стучитесь в открытые двери . Конечно ни один нормальный разработчик не
будет хранить данные в такой структуре . Конечно, это неудобно.
Вы предложили решить эту задачу в SQL - вот решение.
Теперь Вы говорите, что оно сложно выглядит...

Повторюсь - это частный случай задачи транспонирования строк в
столбцы, довольно популярной при развертке таблицы по значениям и
даже располагающейся в FAQ Oracle на сайте (пример разбивки данных
по месяцам)

Она на мой взгляд не является сложной. Я не вижу в ней технических
сложностей. Только некоторая точность и аккуратность. Но естественно в своей системе
мне и в страшном сне не приснилось бы хранить данные в таком виде.
К чему ?

Мне задача была интересна as is , именно как задача на написание запроса...
...
Рейтинг: 0 / 0
30.07.2007, 19:28
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34694021
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
Выбегалло
Да вы наперсточник, батенька.
1. DECODE - в стандарте не прописано.

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


Выбегалло
3. С какой стати DECODE должно быть известно разработчикам других платформ ?
а с какими субд вы имели дело ? DECODE есть и в db2 и в Informix , есть в клонах Postgres (Enterpisedb), наверника в mysql maxdb ...
...
Рейтинг: 0 / 0
30.07.2007, 19:36
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34694025
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
SergSuper пишет:

> Вот тут вот </topic/9021>
> самый классический ЧАЛ, тема почти умирала и 14-й странице он появляется

Даа, классно ! Супермегаотжиг кашесрач на 89 страницах ! Это ж монументальное
полотно просто получилось !

>вот тут
> </topic/282117&pg=7#2591611>
> еще есть ( но сначала всё по первой ссылке прочитайте )

Надеюсь это была шутка...
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
30.07.2007, 19:40
| Ответить | Цитировать | Написать  
25 сообщений из 195, страница 7 из 8
  7  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Разработка СУБД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=35&msg=34693691&tid=1553279]:
 0ms
get settings:
 8ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 32ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 55ms
get tp. blocked users:
 1ms
others: 15ms
total:  142ms
созд. / загр.: 142ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]