Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
 Re: Разработка СУБД  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 122108
Выбегалло
dmidek


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


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


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

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

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 и оставляете только
третий параметр

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. Как там мой примерчик ?
29 июл 07, 11:19    [4449797]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Вот drev - он повыделывался с decode, а потом взял и перевел в стандартные joinы . Типа могет человек. А вы только языком трепать горазды.
29 июл 07, 21:24    [4450393]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
dmidek
Выбегалло
dmidek


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


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


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

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

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 и оставляете только
третий параметр

decode(ColId,1,ColValue,null) A -> ColValue

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



Мне как-то глубоко покласть на ваше мнение о моей (без)грамотности, удивляет только, с какого перепугу вы решили, что оракловские расширения должны быть известны разработчикам других платформ.
А select Андрея - он что без decode, что с decode - работать не будет.
29 июл 07, 21:30    [4450400]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 122108
Выбегалло
Вот drev - он повыделывался с decode, а потом взял и перевел в стандартные joinы . Типа могет человек.


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

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 раз лучше...
29 июл 07, 22:04    [4450451]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
dmidek
Выбегалло
Вот drev - он повыделывался с decode, а потом взял и перевел в стандартные joinы . Типа могет человек.


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

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.
29 июл 07, 22:18    [4450476]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 122108
Выбегалло

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


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

Выбегалло

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


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

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 
29 июл 07, 22:28    [4450484]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 122108
drev
dmidek
Выбегалло
Вот drev - он повыделывался с decode, а потом взял и перевел в стандартные joinы . Типа могет человек.


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

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
29 июл 07, 22:32    [4450493]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
drev
Member

Откуда: Одесса - Берег Красного Дерева - Красный мир
Сообщений: 564
dmidek
Дело вовсе не в этом, у Вас была описка

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



aaa ))))))
29 июл 07, 22:37    [4450501]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Bogdanov Andrey
Member

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

Слава богу, что не вы мне техзадания выдаете. Я приводил пример хранения разреженных массивов в ORACLE. Вас этот пример не устроил тем, что в не смогли перенести его на другие СУБД. Извините, но это идиотизм. Мы либо обсуждаем реализацию разреженных массивов на Oracle, либо на других СУБД. По-поводу Oracle я все сказал, а про другие СУБД ничего говорить не хочу.
30 июл 07, 09:34    [4450956]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Выбегалло
Member

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

Слава богу, что не вы мне техзадания выдаете. Я приводил пример хранения разреженных массивов в ORACLE. Вас этот пример не устроил тем, что в не смогли перенести его на другие СУБД. Извините, но это идиотизм. Мы либо обсуждаем реализацию разреженных массивов на Oracle, либо на других СУБД. По-поводу Oracle я все сказал, а про другие СУБД ничего говорить не хочу.


ничего специфически ораклового в задаче нет, и решается она вполне замечательно средствами стандартного SQL , причем двумя вариантами - с JOIN и с GROUP BY. Не знаю что лично вы обсуждали, а я обсуждал недостатки данной модели, которые на всех СУБД одинаковы - непрозрачность запросов для разработчиков и для оптимизатора. Первую проблему вы прекрасно проиллюстрировали на собственном примере. И это в самом упрощенном варианте. Вы попробуйте написать селект, использующий разные типы данных.
30 июл 07, 10:43    [4451325]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
Выбегалло
ничего специфически ораклового в задаче нет, и решается она вполне замечательно средствами стандартного SQL , причем двумя вариантами - с JOIN и с GROUP BY. Не знаю что лично вы обсуждали, а я обсуждал недостатки данной модели, которые на всех СУБД одинаковы - непрозрачность запросов для разработчиков и для оптимизатора. Первую проблему вы прекрасно проиллюстрировали на собственном примере. И это в самом упрощенном варианте. Вы попробуйте написать селект, использующий разные типы данных.

Не знаю о каких модели вы говорите. Бред в качестве недостатков реляционных СУБД (точнее в качестве примущества cache над реляционными СУБД) назвал неумение ими компактно хранить разреженные массивы. И предложил некий тест, который по его мнению, показывал это неумение. Я своим примером показал, что вопрос компактного хранения - это исключительно вопрос умения спроектировать базу данных. И на oracle "бредовский тест" может быть реализован ровно с теми же параметрами по занимаемому объему, что и на cache.
Вы же почему-то в ответ на это решили обсуждать недостатки какой-то там модели. И при этом, по-всей видимости, занесли меня в сторонники этой самой модели. Давайте отделим мух от котлет. Если вам интересно обсуждать некую модель - пожалуйста, но вряд ли я буду вашим оппонентом.
30 июл 07, 11:23    [4451638]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 122108
Выбегалло
Вы попробуйте написать селект, использующий разные типы данных.


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

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')
/

и вот

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 сделано только для демонстрации явного преобразования типов.
В случае можно конечно проверять дату просто как строку ...
30 июл 07, 11:35    [4451748]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Бред
Guest
softwarer
Бред
Только как-то грустно, что даже не стремитесь к пониманию предмета Вашего труда.

Здравствуйте, Андрей Леонидович.


Ну не ерничайте, Виталий Алексеевич. Прокололись на элементарном непонимании логического уровня, и опять завели песню о чале. Я, как бы Вам этого не хотелось (не совсем, правда, понятно для чего этого так хочется), - не он.
30 июл 07, 17:27    [4454896]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Бред
Guest
Выбегалло
Bogdanov Andrey
Бред
А я просто сравниваю, потому что раздел так называется. Я тоже не ругаю и не хвалю, а привожу результат. Еще раз: у этих колонок могут быть свои ограничения целостности, имена (смысл). Именно Ваш способ и делает тест бессмысленным. Результат Oracle: 1.11 Гб. Я его не ругаю, и не хвалю.

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


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


Пусть чал летит себе с Вашим пером в ж...
Но если реляционные ИДЕЯ (С) порочна, то как ее может спасти "экономное хранение разреженных массивов" ??? Кстати, перечитал высказавания чала (ну может не все), и не нашел ничего про "разреженные массивы", которые невозможно реализовать в рамках "реляционной идеи". После Ваших пламенных и весьма нервных выступлений я уже начал подумывать о том, что не все в порядке с реляционной ИДЕЕЙ (С).
30 июл 07, 17:37    [4454977]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Yo.!
Guest
Выбегалло

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

зашибись позиция, давайте теперь всех заставим ориентироватся на субд которые сумарно занимают 2% рынка :) аналитические функции прописаны в стандарте ANSI SQL и поддерживаются любой нормальной субд.
30 июл 07, 17:46    [4455043]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Бред
Guest
Bogdanov Andrey
Выбегалло
ничего специфически ораклового в задаче нет, и решается она вполне замечательно средствами стандартного SQL , причем двумя вариантами - с JOIN и с GROUP BY. Не знаю что лично вы обсуждали, а я обсуждал недостатки данной модели, которые на всех СУБД одинаковы - непрозрачность запросов для разработчиков и для оптимизатора. Первую проблему вы прекрасно проиллюстрировали на собственном примере. И это в самом упрощенном варианте. Вы попробуйте написать селект, использующий разные типы данных.

Не знаю о каких модели вы говорите. Бред в качестве недостатков реляционных СУБД (точнее в качестве примущества cache над реляционными СУБД) назвал неумение ими компактно хранить разреженные массивы. И предложил некий тест, который по его мнению, показывал это неумение. Я своим примером показал, что вопрос компактного хранения - это исключительно вопрос умения спроектировать базу данных. И на oracle "бредовский тест" может быть реализован ровно с теми же параметрами по занимаемому объему, что и на cache.
Вы же почему-то в ответ на это решили обсуждать недостатки какой-то там модели. И при этом, по-всей видимости, занесли меня в сторонники этой самой модели. Давайте отделим мух от котлет. Если вам интересно обсуждать некую модель - пожалуйста, но вряд ли я буду вашим оппонентом.


Не вводите людей в заблуждение. "Бредовский тест" на Oracle дает 1.11 Гб. Поэтому, наверное, Вы заменили его собственным тестом, умышленно изменив логическую модель. Вы использовали модель, о которой я сказал еще до Вашего сообщения, и которую можно иногда ВЫНУЖДЕННО использовать, получая очень неудобную для прямых запросов структуру. Хотя бы привели пример, когда структуру из Вашего теста УДОБНО И ПРАВИЛЬНО использовать, заменяя ей нормальную структуру данных.
30 июл 07, 17:47    [4455051]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
SergSuper
pavelvp
Если Вы напряжёте свою память, Андрей Леонидович, то наверняка вспомните...

ЧАЛ из Латвии писал, а этот IP московский
Да и стилистика немного другая. Я всё-таки склоняюсь что не он
простите меня люди, был не прав, всё-таки это он
30 июл 07, 18:10    [4455226]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

SergSuper пишет:
> ЧАЛ из Латвии писал, а этот IP московский
> Да и стилистика немного другая. Я всё-таки склоняюсь что не он
>
> простите меня люди, был не прав, всё-таки это он

Дайте пож. ссылку на Чала. На настоящего.

Posted via ActualForum NNTP Server 1.4

30 июл 07, 18:43    [4455425]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32892

Привет, SergSuper!
Ты пишешь:

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

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

Posted via ActualForum NNTP Server 1.4

30 июл 07, 19:01    [4455486]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Yo.!
Выбегалло

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

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


Да вы наперсточник, батенька.
1. DECODE - в стандарте не прописано.
2. Oracle не занимает 98% рынка.
3. С какой стати DECODE должно быть известно разработчикам других платформ ?
30 июл 07, 19:09    [4455519]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
MasterZiv

SergSuper пишет:
> ЧАЛ из Латвии писал, а этот IP московский
> Да и стилистика немного другая. Я всё-таки склоняюсь что не он
>
> простите меня люди, был не прав, всё-таки это он

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


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

вот тут еще есть ( но сначала всё по первой ссылке прочитайте )

Сообщение было отредактировано: 30 июл 07, 19:18
30 июл 07, 19:09    [4455520]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
dmidek
Выбегалло
Вы попробуйте написать селект, использующий разные типы данных.


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

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')
/

и вот

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.
30 июл 07, 19:18    [4455545]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
dmidek
Member

Откуда: Киев - Дортмунд
Сообщений: 122108
Выбегалло
dmidek
Выбегалло
Вы попробуйте написать селект, использующий разные типы данных.


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

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')
/

и вот

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 , именно как задача на написание запроса...
30 июл 07, 19:28    [4455570]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
Yo.!
Guest
Выбегалло

Да вы наперсточник, батенька.
1. DECODE - в стандарте не прописано.

так кто говоришь наперсточник ? :)
Выбегалло

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


Выбегалло

3. С какой стати DECODE должно быть известно разработчикам других платформ ?

а с какими субд вы имели дело ? DECODE есть и в db2 и в Informix, есть в клонах Postgres (Enterpisedb), наверника в mysql maxdb ...
30 июл 07, 19:36    [4455582]     Ответить | Цитировать Сообщить модератору
 Re: Разработка СУБД  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

SergSuper пишет:

> Вот тут вот <https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=9021>
> самый классический ЧАЛ, тема почти умирала и 14-й странице он появляется

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

>вот тут
> <https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=282117&pg=7#2591611>
> еще есть ( но сначала всё по первой ссылке прочитайте )

Надеюсь это была шутка...

Posted via ActualForum NNTP Server 1.4

30 июл 07, 19:40    [4455587]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить