ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Разработка СУБД
195 сообщений из 195, показаны все 8 страниц
  все  
Разработка СУБД
    #34641062
iwe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iwe
Гость
Начал недавно изучать SQL по учебникам intuit.ru.
У меня возник вопрос, не знаю, в правильном ли разделе его задаю...
На фоне все более и более увеличивающейся абстагированности, изолированности средств разработки от компьютерного железа типы данных всё еще остаются очень сильно привязанными к архитектуре... Разве нельзя вместо типа Интегер ввести тип "Штуки" (мы ведь в физическом мире живем, предметы считаем), вместо типов с плавающей точкой - просто "Дробь", ведь есть же "Время" и "Дата"? Да и вообще, не проще ли для контроля типов ввести просто "Число с точкой" и "Число без точки". Пусть СУБД сама решает, где там у меня предел и максимальное значение, а не забивает мне голову планированием сколько байт у меня на что расходуется...
Думаю, это было бы востребовано, ведь непрофессиональных программистов становится всё больше, это общемировая тенденция, так что уберите ноги, и не пинайте сильно.
Жду ваших мнений... Интересно, что думают по этому поводу профи...
...
Рейтинг: 0 / 0
05.07.2007, 14:19
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34641120
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
iwe
Думаю, это было бы востребовано, ведь непрофессиональных программистов
становится всё больше, это общемировая тенденция, так что уберите ноги, и не
пинайте сильно.


Вот это-то и пугает...

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
05.07.2007, 14:33
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34641170
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
iwe
Пусть СУБД сама решает, где там у меня предел и максимальное значение, а не
забивает мне голову планированием сколько байт у меня на что расходуется...

Ну, собственно, многие так и делают. Ты говоришь им DECIMAL, а они уже
решают как его хранить. Ты говоришь DATE, и чтобы понять что же именно у
тебя на выходе, приходится долго рыться в доках.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
05.07.2007, 14:43
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34641216
iwe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iwe
Гость
protector

Вот это-то и пугает...


Я ждал в числе развернутых ответов и такой... %-))))
Оголтелый профи? %-)))
Что страшного в том, что в космос начнут летать не только проф. космонавты, но и пассажиры?
Что страшного, что есть не только водители-профессионалы (сиречь дальнобойщики), но и просто "ездюк" на копейках, которые картошку с дачи возят. Деньги массовых потребителей и непрофессиональных энтузиастов тоже двигают производителей вперед, и нужно еще посмотреть, кто сделал больший вклад в прогресс - профи или потребители...
...
Рейтинг: 0 / 0
05.07.2007, 14:53
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34641245
iwe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iwe
Гость
Dimitry Sibiryakov
Ну, собственно, многие так и делают. Ты говоришь им DECIMAL, а они уже
решают как его хранить. Ты говоришь DATE, и чтобы понять что же именно у
тебя на выходе, приходится долго рыться в доках.
Posted via ActualForum NNTP Server 1.4

В общем-то, мой вопрос можно переформулировать - почему нужно проектировать БД в терминах "плавающий тип", "двойная точность", "целочисленное"... Ведь маска возможного значения - нагляднее...
Непрофессиональному разработчику, ИМХО, нагляднее и надежнее проектируя указать, что номер накладной у меня бесконечно большой, из цифр, и без запятых, а вес яблок - никоглда не отрицателен, но с запятой, и тремя знаками... А уж допустимость операций с данными пусть проверяются в соответствии с этой маской самой СУБД!

Ну, это все отбросив снобизм, конечно....
...
Рейтинг: 0 / 0
05.07.2007, 15:01
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34641253
dm82
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dm82
Гость
iweПусть СУБД сама решает, где там у меня предел и максимальное значение, а не забивает мне голову планированием сколько байт у меня на что расходуется...
А еще лучше пусть она сама за меня думает, что мне надо. В идеальном случае - по жизни 8))) и кофе тоже пусть варит сама. 8)

iwe
это общемировая тенденция
Вспомнилось выражение из одного перевода: "Ты не сможешь остановить глобальный мировой интергационный процесс - это антинаучно"

Ну а по делу, все уже придумано и реализованно... ну или почти все.
В свое время тихо офигивал, читая про разработки 50х - 70х годов.
...
Рейтинг: 0 / 0
05.07.2007, 15:02
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34641342
iwe
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iwe
Гость
dm82Ну а по делу, все уже придумано и реализованно... ну или почти все.
В свое время тихо офигивал, читая про разработки 50х - 70х годов.

Гы-ы-ы-ы... Ну вот, и раз всё уже было придумано и реализовано, то если подумать, все новые версии софта создаются в угоду непрофессионалам... Нафига мне новый ПейджМэйкер, если я знаю, и уже не раз делал газету в Ворде 97, да и скорее всего смогу в ХТМЛе нарисовать и на пленки вывести...
Ну а раз мы до этого договорились, то нужно всё-таки ждать типа данных "пары обуви", "штуки", "кг"... если уже сейчас есть Дата и Время; а то можно было без проблем время в секундах считать, как комп и считает, причем хоть от рождения Магомета, хоть от Иисусечега, а хоть от 1970 года...
...
Рейтинг: 0 / 0
05.07.2007, 15:22
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34642130
ЮВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЮВ
Участник
iweРазве нельзя вместо типа Интегер ввести тип "Штуки" (мы ведь в физическом мире живем, предметы считаем), вместо типов с плавающей точкой - просто "Дробь", ведь есть же "Время" и "Дата"? Да и вообще, не проще ли для контроля типов ввести просто "Число с точкой" и "Число без точки".
...
Интересно, что думают по этому поводу профи...

Я не профи, но все равно выскажусь.
1 Откажитесь от встроенных типов данных.
2 Предоставьте пользователю возможность и средства для описания собственных (абстрактных) типов данных. Оператор typedef в СУБД.
3 Работайте с созданными пользователем типами данных.

Это один путь.

По второму пути идут разработчики различных интерфейсов доступа к БД.
Они ничего не меняют в существующих СУБД, но позволяют пользователям создавать собственые типы данных (средствами своих интерфейсов).
А для каждой конкретной СУБД пишется свой провайдер (драйвер), которой преобразует пользовательские типы данных в типы данных СУБД (как в одном направленни - от клиента к СУБД, так и в обратном).
...
Рейтинг: 0 / 0
05.07.2007, 18:17
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34642359
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nik_x
Участник
2: iwe
Для начала НЕОБХОДИМО уяснить отличия между СУБД и БД.
А апосля этого, подобные вопросы отвалятся сами собой...
...
Рейтинг: 0 / 0
05.07.2007, 19:51
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34642575
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
nik_x2: iwe
Для начала НЕОБХОДИМО уяснить отличия между СУБД и БД.
А апосля этого, подобные вопросы отвалятся сами собой...
а поконкретней?

(просто чем так отвечать - лучше ничего не отвечать. какой-то намёк на свою посвященность. хотя вопрос на мой взгляд довольно поверхностный)
...
Рейтинг: 0 / 0
05.07.2007, 23:55
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34642587
zloy den
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zloy den
Участник
А не усложнит ли это в итоге разработку?
Мне пожалуй будет проще самому определить что и как у меня хранится(на уровне нынешних СУБД), чем гадать что оно там запихнуло и как его оттуда достать?
Т.е. очень простое приложение возможно и будет проще написать, а что посложнее потребует наоборот больших трудозатрат.
К тому же если не будет очень стройной концепции этой приблуды, то она будет источником лишних глюков и тормозов. Мало сделать абстрактную надстройку для увеличения надежности, нужно еще и сделать ее настолько хорошо, чтобы не пришлось потом долго и упорно ковыряться в поисках плавающих глюков. В случае закрытого кода это может нафиг убить эту разработку(хотя может и в случае открытого)
...
Рейтинг: 0 / 0
06.07.2007, 00:11
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34644035
denis_viktorovich
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
denis_viktorovich
Участник
iwe protector

Вот это-то и пугает...

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

Ну и пусть ездят. Но вы предлагаете чтобы космические корабли и грузовики конструировали потребители. А это уже страшновато.
...
Рейтинг: 0 / 0
06.07.2007, 14:40
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34644253
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
iweНачал недавно изучать SQL по учебникам intuit.ru.
У меня возник вопрос, не знаю, в правильном ли разделе его задаю...
На фоне все более и более увеличивающейся абстагированности, изолированности средств разработки от компьютерного железа типы данных всё еще остаются очень сильно привязанными к архитектуре... Разве нельзя вместо типа Интегер ввести тип "Штуки" (мы ведь в физическом мире живем, предметы считаем), вместо типов с плавающей точкой - просто "Дробь", ведь есть же "Время" и "Дата"? Да и вообще, не проще ли для контроля типов ввести просто "Число с точкой" и "Число без точки". Пусть СУБД сама решает, где там у меня предел и максимальное значение, а не забивает мне голову планированием сколько байт у меня на что расходуется...
Думаю, это было бы востребовано, ведь непрофессиональных программистов становится всё больше, это общемировая тенденция, так что уберите ноги, и не пинайте сильно.
Жду ваших мнений... Интересно, что думают по этому поводу профи...

Вам надо было с забвенным чалом это обсуждать. Ярым сторонником баз данных без программистов.
...
Рейтинг: 0 / 0
06.07.2007, 15:32
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34647311
Фотография Владимир П.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир П.
Участник
iweРазве нельзя вместо типа Интегер ввести тип "Штуки" (мы ведь в физическом мире живем, предметы считаем), вместо типов с плавающей точкой - просто "Дробь", ведь есть же "Время" и "Дата"?
Можно. На этапе проектирования и создания базы заведите эти типы сами, CREATE DOMAIN еще никто не отменял.
...
Рейтинг: 0 / 0
09.07.2007, 13:17
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34654191
Plisteron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Plisteron
Гость
iweНачал недавно изучать SQL по учебникам intuit.ru.
У меня возник вопрос, не знаю, в правильном ли разделе его задаю...
На фоне все более и более увеличивающейся абстагированности, изолированности средств разработки от компьютерного железа типы данных всё еще остаются очень сильно привязанными к архитектуре... Разве нельзя вместо типа Интегер ввести тип "Штуки" (мы ведь в физическом мире живем, предметы считаем), вместо типов с плавающей точкой - просто "Дробь", ведь есть же "Время" и "Дата"? Да и вообще, не проще ли для контроля типов ввести просто "Число с точкой" и "Число без точки". Пусть СУБД сама решает, где там у меня предел и максимальное значение, а не забивает мне голову планированием сколько байт у меня на что расходуется...
Думаю, это было бы востребовано, ведь непрофессиональных программистов становится всё больше, это общемировая тенденция, так что уберите ноги, и не пинайте сильно.
Жду ваших мнений... Интересно, что думают по этому поводу профи...
Под СУБД Вы Access подразумеваете?
Код: plaintext
1.
2.
3.
4.
5.
CREATE TABLE DUMMY
(
    FIELD1 FLOAT,
    FIELD2 NUMBER( 5 ,  2 ),
    FIELD3 NUMBER( 8 , 0 )
);
Вот так можно в том же Oracle: и число с точкой и без точки и с точкой "где-то там".
А для "штук", как справедливо заметил "Владимир П." есть домены.
...
Рейтинг: 0 / 0
11.07.2007, 16:55
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34654236
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
Plisteronесть домены.

В Oracle ???
...
Рейтинг: 0 / 0
11.07.2007, 17:05
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34655146
Фотография Владимир П.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Владимир П.
Участник
В Oracle доменов конечно нет, но в мире существует не только Oracle. Если автор дискуссии никак жить не может без того, чтобы
iweввести тип "Штуки" (мы ведь в физическом мире живем, предметы считаем)
, то Oracle ему рекомендовать нельзя. Пусть выбирает FireBird, PostgreSQL.
...
Рейтинг: 0 / 0
12.07.2007, 08:23
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34655219
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
Просто товарищч Plisteron дебютировав на форуме УЖЕ успел сказать много разной ФИГНИ.

прошу рассматривать это не как переход на личности, а как предостережение тем кто читает его посты
...
Рейтинг: 0 / 0
12.07.2007, 08:58
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34662520
ArcticFox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ArcticFox
Гость
iwe Dimitry Sibiryakov
Ну, собственно, многие так и делают. Ты говоришь им DECIMAL, а они уже
решают как его хранить. Ты говоришь DATE, и чтобы понять что же именно у
тебя на выходе, приходится долго рыться в доках.
Posted via ActualForum NNTP Server 1.4

В общем-то, мой вопрос можно переформулировать - почему нужно проектировать БД в терминах "плавающий тип", "двойная точность", "целочисленное"... Ведь маска возможного значения - нагляднее...
Непрофессиональному разработчику, ИМХО, нагляднее и надежнее проектируя указать, что номер накладной у меня бесконечно большой, из цифр, и без запятых, а вес яблок - никоглда не отрицателен, но с запятой, и тремя знаками... А уж допустимость операций с данными пусть проверяются в соответствии с этой маской самой СУБД!

Ну, это все отбросив снобизм, конечно....

Отбросили мы снобизм, теперь читаем код и медленно ох...
...
Рейтинг: 0 / 0
16.07.2007, 21:27
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34663042
RomanSavelyev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RomanSavelyev
Гость
iweРазве нельзя вместо типа Интегер ввести тип "Штуки"
Можно.
Во всех СУБД, кроме совсем уж игрушечных, есть возможность определения собственных типов данных.
Определяйте "штуки" и работайте.

Но учтите, что всего на 1 миллион записей (а это не много), "штуки" займут:
small - 16 миллионов байт.
integer - 32 миллиона байт
bigint - 64 миллиона.
Плюс такие же веса в индексах.
В конце концов, в Oracle вы можете просто сказать "numeric".

(мы ведь в физическом мире живем, предметы считаем), вместо типов с плавающей точкой - просто "Дробь", ведь есть же "Время" и "Дата"
А такое есть. Decimal
И есть не для "естественности восприятия", а для правильного (и точного) хранения чисел фиксированной разрядности.

Да и вообще, не проще ли для контроля типов ввести просто "Число с точкой" и "Число без точки". Пусть СУБД сама решает, где там у меня предел и максимальное значение, а не забивает мне голову планированием сколько байт у меня на что расходуется...
Думаю, это было бы востребовано, ведь непрофессиональных программистов становится всё больше, это общемировая тенденция, так что уберите ноги, и не пинайте сильно.
Жду ваших мнений... Интересно, что думают по этому поводу профи...
Это всё хорошо, но попробуйте профильтровать сие через среднепаршивые промышленные объемы данных.
Как в части скорости работы, так и в части пространства для хранения.
...
Рейтинг: 0 / 0
17.07.2007, 10:05
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34663649
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
RomanSavelyevНо учтите, что всего на 1 миллион записей (а это не много), "штуки" займут:
small - 16 миллионов байт.
integer - 32 миллиона байт
bigint - 64 миллиона.
...
Это в какой СУБД small занимает 16 байт ?
...
Рейтинг: 0 / 0
17.07.2007, 12:30
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34663746
ZoomPro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ZoomPro
Гость
ChA RomanSavelyevНо учтите, что всего на 1 миллион записей (а это не много), "штуки" займут:
small - 16 миллионов байт.
integer - 32 миллиона байт
bigint - 64 миллиона.
...
Это в какой СУБД small занимает 16 байт ?
Ну че придираешься, опечатался он - думал ьиты - написал байты.
А вообще автор говорит здравые мысли, пора появляться универсальным типам данных не привязанным ни к каким платформам. В этом направлении и Microsoft работает уже давно .NET делая. А кроме этого еще масса других попыток. Все правильно, универсальный элементарные типы - это будет.
...
Рейтинг: 0 / 0
17.07.2007, 12:54
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34664889
RomanSavelyev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
RomanSavelyev
Гость
Это в какой СУБД small занимает 16 байт ?
Бит, конечно же.

Но!
Типы данных давно стандартизованы. И элементарные типы покрывают 99% потребности.
Там, где действительно нужны комплексные типы (GIS и т.п.) - они есть.

Но мы и так приходим к тому, что дизайнер БД не задумывается о типах данных и подводит нас к покупке нового массива данных.
По моему, дизайнер БД всё-таки должен представлять, каков принцип хранения типа, да каким боком сие чревато.
...
Рейтинг: 0 / 0
17.07.2007, 16:50
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34674672
Lepsik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lepsik
Участник
ZoomProпривязанным ни к каким платформам. В этом направлении и Microsoft работает уже давно .NET делая.

И каков итог ? Пообещали WinFS основанный на базе и втихаря подальше от позора его отрезали от Висtы
...
Рейтинг: 0 / 0
20.07.2007, 22:13
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34675489
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
RomanSavelyev
Да и вообще, не проще ли для контроля типов ввести просто "Число с точкой" и "Число без точки". Пусть СУБД сама решает, где там у меня предел и максимальное значение, а не забивает мне голову планированием сколько байт у меня на что расходуется...
Думаю, это было бы востребовано, ведь непрофессиональных программистов становится всё больше, это общемировая тенденция, так что уберите ноги, и не пинайте сильно.
Жду ваших мнений... Интересно, что думают по этому поводу профи...
Это всё хорошо, но попробуйте профильтровать сие через среднепаршивые промышленные объемы данных.
Как в части скорости работы, так и в части пространства для хранения.


Пару раз сталкивался с ситуацией, когда именно объём хранения являлся причиной отказа от СУБД
...
Рейтинг: 0 / 0
22.07.2007, 13:11
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34675882
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Владимир П.В Oracle доменов конечно нет, но в мире существует не только Oracle. Если автор дискуссии никак жить не может без того, чтобы
iweввести тип "Штуки" (мы ведь в физическом мире живем, предметы считаем)
, то Oracle ему рекомендовать нельзя. Пусть выбирает FireBird, PostgreSQL.
Оракл, вообще-то, заявляет себя как ОРСУБД. Т.е. свои "штуки" можно пробовать - объектный тип данных. Для ГИС у Оракла, напрмер, начиная с 9 предлагается ОРМД, т.е для этих задач Штуки от самого Оракла.
Другое дело, что из этого получится. Разаработка своих штук не совсем не профессиональное занятие: ведь основным недостатком ООП в либых областях считается именно сложность. Достаточно взглянуть на библиотеки классов для С#,Jdeveloper (Oracle) и проч, и представить, что вы их сами налабали, и они плохо спроектированы. Поддерживать их, наверное, похуже будет, чем процедурные библиотеки.
...
Рейтинг: 0 / 0
22.07.2007, 22:55
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34680271
DocAl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DocAl
Участник
ZoomPro
А вообще автор говорит здравые мысли, пора появляться универсальным типам данных не привязанным ни к каким платформам. В этом направлении и Microsoft работает уже давно .NET делая. А кроме этого еще масса других попыток. Все правильно, универсальный элементарные типы - это будет.IMHO, "платформонезависимые продукты от Microsoft" -- это что-то вроде разноцветных автомобилей Генри Форда.
...
Рейтинг: 0 / 0
24.07.2007, 14:42
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34680509
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
DocAl ZoomPro
А вообще автор говорит здравые мысли, пора появляться универсальным типам данных не привязанным ни к каким платформам. В этом направлении и Microsoft работает уже давно .NET делая. А кроме этого еще масса других попыток. Все правильно, универсальный элементарные типы - это будет.IMHO, "платформонезависимые продукты от Microsoft" -- это что-то вроде разноцветных автомобилей Генри Форда.

я видел желтый форд
...
Рейтинг: 0 / 0
24.07.2007, 15:30
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34680565
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, Gluk!
Ты пишешь:

GlukGK> я видел желтый форд пираты (сцуки) контрафакт гонють...

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

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
24.07.2007, 15:44
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34680959
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
RomanSavelyev iweРазве нельзя вместо типа Интегер ввести тип "Штуки"
Можно.
Во всех СУБД, кроме совсем уж игрушечных, есть возможность определения собственных типов данных.
Определяйте "штуки" и работайте.

Но учтите, что всего на 1 миллион записей (а это не много), "штуки" займут:
small - 16 миллионов байт.
integer - 32 миллиона байт
bigint - 64 миллиона.
Плюс такие же веса в индексах.


Может чего не правильно настроил:

В таблице 1000 колонок типа Integer.
1 000 000 записей, и только в одной колонке каждой записи записал значение=1.

SQL Server 2005 - 17.2 Gb
Cache 5.2 - 17 Mb

И, если кто может, скажите какой результат в Oracle?
...
Рейтинг: 0 / 0
24.07.2007, 17:05
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681148
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
да нет, примерно так и должно быть
а что Вас удивляет?
...
Рейтинг: 0 / 0
24.07.2007, 17:50
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681149
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
БредSQL Server 2005 - 17.2 Gb
Cache 5.2 - 17 Mb

И, если кто может, скажите какой результат в Oracle?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
Connected to Oracle Database 10g Enterprise Edition Release  10 . 1 . 0 . 5 . 0  
Connected as test

SQL> create table many_columns ( id integer ) pctfree  0  ;

Table created

SQL> begin
   2     for i in  1 .. 999  loop
   3       execute immediate 'alter table many_columns add col' || i || ' integer' ;
   4     end loop ;
   5   end ;
   6   /

PL/SQL procedure successfully completed

SQL> insert into many_columns ( id ) select rownum from dual connect by level <=  1000000  ;

 1000000  rows inserted

SQL> select bytes from dba_segments where segment_name = 'MANY_COLUMNS' ;

     BYTES
----------
   11534336
...
Рейтинг: 0 / 0
24.07.2007, 17:50
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681221
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
SergSuperда нет, примерно так и должно быть
а что Вас удивляет?

Спасибо.
...
Рейтинг: 0 / 0
24.07.2007, 18:04
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681228
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer БредSQL Server 2005 - 17.2 Gb
Cache 5.2 - 17 Mb

И, если кто может, скажите какой результат в Oracle?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
Connected to Oracle Database 10g Enterprise Edition Release  10 . 1 . 0 . 5 . 0  
Connected as test

SQL> create table many_columns ( id integer ) pctfree  0  ;

Table created

SQL> begin
   2     for i in  1 .. 999  loop
   3       execute immediate 'alter table many_columns add col' || i || ' integer' ;
   4     end loop ;
   5   end ;
   6   /

PL/SQL procedure successfully completed

SQL> insert into many_columns ( id ) select rownum from dual connect by level <=  1000000  ;

 1000000  rows inserted

SQL> select bytes from dba_segments where segment_name = 'MANY_COLUMNS' ;

     BYTES
----------
   11534336


Спасибо, но, често скажу, не совсем понял. Для определенности: прописать значение 1 в последнюю колонку каждой записи (при этом в SQL Server и Cache ничего не изменится).
...
Рейтинг: 0 / 0
24.07.2007, 18:06
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681268
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
БредСпасибо, но, често скажу, не совсем понял.
Это я в том числе к тому, что вопрос довольно бессмысленный.

БредДля определенности: прописать значение 1 в последнюю колонку каждой записи (при этом в SQL Server и Cache ничего не изменится).
Добавится по 999 байт на строку.
...
Рейтинг: 0 / 0
24.07.2007, 18:21
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681379
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer БредСпасибо, но, често скажу, не совсем понял.
Это я в том числе к тому, что вопрос довольно бессмысленный.

БредДля определенности: прописать значение 1 в последнюю колонку каждой записи (при этом в SQL Server и Cache ничего не изменится).
Добавится по 999 байт на строку.

Большое спасибо. Пусть и бессмысленный, но результат:

В таблице 1000 колонок типа Integer.
1 000 000 записей, и только в последней колонке каждой записи записали значение=1.

SQL Server 2005 - 17.2 Gb
Cache 5.2 - 17 Mb
Oracle ??? - 1.11 Gb

А разве любой из таких вот "отдельных результатов" нельзя назвать бессмысленным?
Наверное нужно закрывать этот раздел на форуме.
...
Рейтинг: 0 / 0
24.07.2007, 19:01
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681391
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
БредА разве любой из таких вот "отдельных результатов" нельзя назвать бессмысленным?
Можно. Однако, некоторые отдельные результаты остаются бессмысленными в любом реальном контексте.

Допустим, я скажу Вам, что стрелка индикатора бензина в автомобиле X-123 весит полтора грамма, а в автомобиле Y-124 - два с половиной грамма. Сумеете ли Вы найти полезное применение этой информации? Или на основании этого сделаете вывод о бессмысленности сравнения автомобилей?
...
Рейтинг: 0 / 0
24.07.2007, 19:07
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681409
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer БредА разве любой из таких вот "отдельных результатов" нельзя назвать бессмысленным?
Можно. Однако, некоторые отдельные результаты остаются бессмысленными в любом реальном контексте.

Допустим, я скажу Вам, что стрелка индикатора бензина в автомобиле X-123 весит полтора грамма, а в автомобиле Y-124 - два с половиной грамма. Сумеете ли Вы найти полезное применение этой информации? Или на основании этого сделаете вывод о бессмысленности сравнения автомобилей?

Я про стрелки в автомобиле, кажется, ничего не говорил, но говорил про базы данных, кажется. А именно про хранение "сильно разреженных таблиц", в которых иногда есть потребность. Но пусть это будет совершенно бессмысленным, в отличие от Ваших, всегда осмысленных, "сравнениях СУБД". Я не против.
...
Рейтинг: 0 / 0
24.07.2007, 19:14
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681426
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
Бред А именно про хранение "сильно разреженных таблиц", в которых иногда есть потребность. Но пусть это будет совершенно бессмысленным, в отличие от Ваших, всегда осмысленных, "сравнениях СУБД". Я не против.
"сильно разреженные таблицы" бывают только от разрухи в головах
если проектиовать с учетом какие данные будут храниться никакой сильноразреженности не будет
...
Рейтинг: 0 / 0
24.07.2007, 19:22
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681427
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
БредА именно про хранение "сильно разреженных таблиц", в которых иногда есть потребность.
В хранении "сильно разреженных таблиц" потребности нет. Может быть потребность хранения сильно разреженных данных и есть те или иные приемы ее реализации в той или иной СУБД - скажем, перенос ненулевых колонок в начало, скажем, вертикальное партиционирование, а то и вовсе какой-нибудь EAV-like design.

Соответственно, сравнивать результаты на жестко заданной архитектуре хранения - бессмысленно, если цель - именно сравнение. Можно сравнивать именно решения той или иной задачи - с учетом эффективности решения основной задачи, эффективности других, более редких, но ожидаемых операций и удобства собственно реализации.
...
Рейтинг: 0 / 0
24.07.2007, 19:22
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681433
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
softwarer...
какая у нас аллергия на сильноразреженность
...
Рейтинг: 0 / 0
24.07.2007, 19:26
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681438
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
SergSuper Бред А именно про хранение "сильно разреженных таблиц", в которых иногда есть потребность. Но пусть это будет совершенно бессмысленным, в отличие от Ваших, всегда осмысленных, "сравнениях СУБД". Я не против.
"сильно разреженные таблицы" бывают только от разрухи в головах
если проектиовать с учетом какие данные будут храниться никакой сильноразреженности не будет

Да понятно уже у кого разруха в голове. Спасибо.
P.S. Типичная борьба с разреженностью в SQL БД: хранить данные в таблице:
Строка
Колонка
Значение типа дата
Значение типа число
Значение типа строка
Еще полезно создавать новые таблицы динамически.
И никакой разрухи в голове.
...
Рейтинг: 0 / 0
24.07.2007, 19:28
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681445
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer БредА именно про хранение "сильно разреженных таблиц", в которых иногда есть потребность.
В хранении "сильно разреженных таблиц" потребности нет. Может быть потребность хранения сильно разреженных данных и есть те или иные приемы ее реализации в той или иной СУБД - скажем, перенос ненулевых колонок в начало, скажем, вертикальное партиционирование, а то и вовсе какой-нибудь EAV-like design.

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

Спасибо. Поправили терминологию и предложили, как я понял, "вертикальное" партиционирование" в Oracle. Понятно.
...
Рейтинг: 0 / 0
24.07.2007, 19:32
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681449
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
БредСпасибо. Поправили терминологию
Если Вы воспринимаете именно так - Ваше право.
...
Рейтинг: 0 / 0
24.07.2007, 19:35
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681464
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
Бред
P.S. Типичная борьба с разреженностью в SQL БД: хранить данные в таблице:
Строка
Колонка
Значение типа дата
Значение типа число
Значение типа строка
Еще полезно создавать новые таблицы динамически.
И никакой разрухи в голове.
Как будто Cache хранит по другому
(правда там 3-й и 4-й позиции нет, всё только строкой храниться)
...
Рейтинг: 0 / 0
24.07.2007, 19:39
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681470
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
SergSuperпримерно так и должно бытьНе уверен, должно быть меньше, ориентировочно раза в 3-4:

4Б * 1000 полей * 1 000 000 записей ~ 4 000 000 000 ~ 4ГБ

Так что похоже, эксперимент был проведен не очень чисто.
...
Рейтинг: 0 / 0
24.07.2007, 19:42
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681472
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer БредСпасибо. Поправили терминологию
Если Вы воспринимаете именно так - Ваше право.

Значит ли это, что "вертикальное партиционирование" в Oracle отпадает, и нужно реализовывать в Oracle "какой-нибудь EAV-like dasign" мне сложно понять. И это, надо думать, тоже мое право.
...
Рейтинг: 0 / 0
24.07.2007, 19:43
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681476
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
ChA SergSuperпримерно так и должно бытьНе уверен, должно быть меньше, ориентировочно раза в 3-4:

4Б * 1000 полей * 1 000 000 записей ~ 4 000 000 000 ~ 4ГБ

Так что похоже, эксперимент был проведен не очень чисто.

Списибо. Я не смог обнаружить нечистоту, к сожалению, и обратился с вопросом к специалистам.
...
Рейтинг: 0 / 0
24.07.2007, 19:46
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681486
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
SergSuper Бред
P.S. Типичная борьба с разреженностью в SQL БД: хранить данные в таблице:
Строка
Колонка
Значение типа дата
Значение типа число
Значение типа строка
Еще полезно создавать новые таблицы динамически.
И никакой разрухи в голове.
Как будто Cache хранит по другому
(правда там 3-й и 4-й позиции нет, всё только строкой храниться)

Там разные способы хранения, и не совсем понятно о чем Вы говорите. В любом случае там не нужно бороться с разреженностью - количество колонок в таблице не ограничено.
...
Рейтинг: 0 / 0
24.07.2007, 19:49
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681487
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
БредЯ не смог обнаружить нечистоту, к сожалению, и обратился с вопросом к специалистам.В данном случае лучше было писать "не" и "чистоту" раздельно, хотя фразу это все равно не спасает. Начнем с того, как Вы определили объем БД после выполнения всех операций ? В EM в свойствах БД посмотрели ?
...
Рейтинг: 0 / 0
24.07.2007, 19:49
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681489
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
БредЗначит ли это, что "вертикальное партиционирование" в Oracle отпадает, и нужно реализовывать в Oracle "какой-нибудь EAV-like dasign" мне сложно понять.
Попробуйте спросить у Гугля, что эти слова значат - может, станет яснее. Правда, не ответит на вопрос "что же нужно реализовывать" - например, разреженные данные очень эффективно хранятся в analytic workspace-ах, но это не значит, что их надо использовать для каждой задачи.

БредИ это, надо думать, тоже мое право.
Безусловно.
...
Рейтинг: 0 / 0
24.07.2007, 19:50
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681494
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
ChA БредЯ не смог обнаружить нечистоту, к сожалению, и обратился с вопросом к специалистам.В данном случае лучше было писать "не" и "чистоту" раздельно, хотя фразу это все равно не спасает. Начнем с того, как Вы определили объем БД после выполнения всех операций ? В EM в свойствах БД посмотрели ?

Закончите, пожалуйста, тем каков правильный результат, и дело с концом. Я же уже согласился с полной бессмысленностью.
...
Рейтинг: 0 / 0
24.07.2007, 19:51
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681500
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
ChA БредЯ не смог обнаружить нечистоту, к сожалению, и обратился с вопросом к специалистам.В данном случае лучше было писать "не" и "чистоту" раздельно,

Это было бы орфографической ошибкой.
...
Рейтинг: 0 / 0
24.07.2007, 19:54
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681505
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
SergSuperкакая у нас аллергия на сильноразреженность
Она в природе человеческой. Мы же не радуемся сильно разреженным товарам в магазинах и не отправляемся в отпуск с сильно разреженными вещами в чемоданах
...
Рейтинг: 0 / 0
24.07.2007, 19:56
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681510
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
БредЗакончите, пожалуйста, тем каков правильный результат, и дело с концом. Я же уже согласился с полной бессмысленностью.Я не знаю, что Вы подразумеваете под правильным результатом. Грубый пример стандартного расчета объема таблицы уже был приведен. Все сильные отклонения от него могут быть результатом неизвестных мне факторов.
...
Рейтинг: 0 / 0
24.07.2007, 19:59
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681513
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
MasterZivЭто было бы орфографической ошибкой. Модератор: Давайте остановимся на этом?
...
Рейтинг: 0 / 0
24.07.2007, 20:01
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681519
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
БредТам разные способы хранения, и не совсем понятно о чем Вы говорите. В любом случае там не нужно бороться с разреженностью - количество колонок в таблице не ограничено.
Способы может быть и разные, но все сводится к одному - есть некий ключ и аттрибут. Сделайте так же на SQL - и тоже не надо будет бороться
...
Рейтинг: 0 / 0
24.07.2007, 20:03
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681520
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer SergSuperкакая у нас аллергия на сильноразреженность
Она в природе человеческой. Мы же не радуемся сильно разреженным товарам в магазинах и не отправляемся в отпуск с сильно разреженными вещами в чемоданах

Интересный пример с чемоданами. Сложно представить что-либо более разреженное. Я уж не говорю, что в любом магазине просто потрясающая разреженность товаров. Постоянно большинство нужных предметов нельзя купить в конкретном магазине...
...
Рейтинг: 0 / 0
24.07.2007, 20:04
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681528
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
SergSuper БредТам разные способы хранения, и не совсем понятно о чем Вы говорите. В любом случае там не нужно бороться с разреженностью - количество колонок в таблице не ограничено.
Способы может быть и разные, но все сводится к одному - есть некий ключ и аттрибут. Сделайте так же на SQL - и тоже не надо будет бороться

Вы мне предлагаете сделать количество колонок в таблице не ограниченным, и не занимать место под несуществующие данные в SQL Server ??? Я этого сделать не могу.
...
Рейтинг: 0 / 0
24.07.2007, 20:08
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681534
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
БредЯ уж не говорю, что в любом магазине просто потрясающая разреженность товаров. Постоянно большинство нужных предметов нельзя купить в конкретном магазине...
"Потрясающая разреженность" здесь относится к "товарам в совокупности", к тому, что я назвал "данными", противопоставив их "таблицам". То, что Вы предпочли трактовать как поправку в терминологии.

Магазины - как раз пример вертикального партиционирования как варианта хранения разреженных данных. Благодаря ему во-первых полки магазина плотно забиты, во-вторых, гвозди как правило можно купить рядом с молотками, а в-третьих, покупая хлеб, мы не рискуем обнаружить в нем завалившийся гвоздь.
...
Рейтинг: 0 / 0
24.07.2007, 20:10
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681535
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
ChA БредЗакончите, пожалуйста, тем каков правильный результат, и дело с концом. Я же уже согласился с полной бессмысленностью.Я не знаю, что Вы подразумеваете под правильным результатом. Грубый пример стандартного расчета объема таблицы уже был приведен. Все сильные отклонения от него могут быть результатом неизвестных мне факторов.

Я могу только предположить, что в Вашем грубом примере есть серьезная ошибка. Но, предположим, что ошибка была у меня (куда-то не туда смотрел). Тогда:

SQL Server 2005 - 4 Гб
Cache 5.2 - 17 Мб
Oracle ??? - 1.11 Гб
...
Рейтинг: 0 / 0
24.07.2007, 20:12
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681542
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer БредЯ уж не говорю, что в любом магазине просто потрясающая разреженность товаров. Постоянно большинство нужных предметов нельзя купить в конкретном магазине...
"Потрясающая разреженность" здесь относится к "товарам в совокупности", к тому, что я назвал "данными", противопоставив их "таблицам". То, что Вы предпочли трактовать как поправку в терминологии.

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

Лирика. Вы продолжаете настаивать на том, что данные могут быть разреженными (что это такое я понять не могу - не дано), а таблицы не могут. На этой оптимистической ноте позвольте закончить обсуждение изначально бессмысленного вопроса.
...
Рейтинг: 0 / 0
24.07.2007, 20:17
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681548
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
MasterZivЭто было бы орфографической ошибкой.Уважаемый MasterZiv, рекомедую Вам ознакомиться со смыслом слова "нечистота", например, с помощью Google.

P.S. Модератор, так лучше ?
Модератор: Уважаемый ChA, рекомендую Вам ознакомиться с правилами хорошего тона
...
Рейтинг: 0 / 0
24.07.2007, 20:20
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681552
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
БредТам разные способы хранения, и не совсем понятно о чем Вы говорите. В любом случае там не нужно бороться с разреженностью - количество колонок в таблице не ограничено. Конечно не ограничено. Ведь там нет ни того, ни другого. Ограничение на размер "ключа" всё же есть.
...
Рейтинг: 0 / 0
24.07.2007, 20:22
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681753
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
БредВы мне предлагаете сделать количество колонок в таблице не ограниченным, и не занимать место под несуществующие данные в SQL Server ??? Я этого сделать не могу.
Я ничего не предлагаю, я просто объясняю что структура данных в Cache эквивалентна таблице с двумя полями. Снимаю шляпу перед маркетологами Cache, которые для этого сумели придумать красивое название "разряженные массивы"
...
Рейтинг: 0 / 0
24.07.2007, 23:02
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681836
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
БредБольшое спасибо. Пусть и бессмысленный, но результат:

В таблице 1000 колонок типа Integer.
1 000 000 записей, и только в последней колонке каждой записи записали значение=1.

SQL Server 2005 - 17.2 Gb
Cache 5.2 - 17 Mb
Oracle ??? - 1.11 Gb

А разве любой из таких вот "отдельных результатов" нельзя назвать бессмысленным?
Наверное нужно закрывать этот раздел на форуме.Гм. Не знаю - зачем я это делал :), но вот результаты Firebird
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
execute block returns (s varchar( 20080 ))
as
declare i int;
begin
  s = 'create table t (id int)';
  execute statement :s;
  suspend;

  s = '';
  i =  1 ;
  while (i <  1000 ) do
  begin
    if (char_length(s) <  20000  or s = '')
    then begin
      if (s = '')
      then s = 'alter table t add col' || i || ' int';
      else s = s || ', add col' || i || ' int';
    end
    else begin
      execute statement :s;
      suspend;

      s = '';
    end

    i = i +  1 ;
  end

  if (s <> '')
  then begin
    execute statement :s;
    suspend;
  end
end;
commit;
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
execute block as
declare i int =  0 ;
begin
  while (i <  1000000 ) do
  begin
    insert into t (id) values (:i);
    i = i +  1 ;
  end
end
commit;
Сразу после этого :
Код: plaintext
1.
Data pages: 14085, data page slots: 14085, average fill: 79%
Average record length: 73.93, total records: 1000000
Размер страницы 8К, т.е. имеем 112680КБ или 110МБ

Заносим 1 в последнюю колонку :
Код: plaintext
update t set col999 =  1
Статистика :
Код: plaintext
1.
    Average record length: 77.26, total records: 1000000 
    Data pages: 16796, data page slots: 16796, average fill: 98%
Т.е. 134368КБ или 131МБ
...
Рейтинг: 0 / 0
25.07.2007, 01:37
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681841
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Гм, чего-то со скриптом я намутил - ночь наверное ;) Создавать таблицу можно и так

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
execute block returns (s varchar( 64 ))
as
declare i int =  1 ;
begin
  s = 'create table t (id int)';
  execute statement :s;
  suspend;

  while (i <  1000 ) do
  begin
    s = 'alter table t add col' || i || ' int';
    execute statement :s;
    suspend;

    i = i +  1 ;
  end
end;
commit;
Суть от этого, конечно, не меняется
...
Рейтинг: 0 / 0
25.07.2007, 01:48
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34681846
Пьяный Лох
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Пьяный Лох
Участник
Простите, а где ЧАЛ?
...
Рейтинг: 0 / 0
25.07.2007, 02:01
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34682041
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
БредМожет чего не правильно настроил:

В таблице 1000 колонок типа Integer.
1 000 000 записей, и только в одной колонке каждой записи записал значение=1.

SQL Server 2005 - 17.2 Gb
Cache 5.2 - 17 Mb

И, если кто может, скажите какой результат в Oracle?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
SQL> create table EmptyTable
   2   (RecordId integer,
   3   ColId integer,
   4   CalValue integer)
   5   storage(initial 1M next  0 );

Table created.

SQL> insert into EmptyTable(RecordId,ColId,CalValue)
   2   select n, 1000 , 1  from (select rownum n from dual connect by level <  1000001 );

 1000000  rows created.

SQL> select bytes/ 1024 / 1024  from dba_segments where segment_name=upper('EmptyTable');

BYTES/ 1024 / 1024 
---------------
              18

То есть 18 Mb. Это слегка завышенная цифра, так как место выделяется экстентами. Без увеличения размера в эту табличку можно добавить еще около ста тысяч записей.
...
Рейтинг: 0 / 0
25.07.2007, 09:18
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34684390
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
Бред говорил про базы данных, кажется. А именно про хранение "сильно разреженных таблиц", в которых иногда есть потребность. Но пусть это будет совершенно бессмысленным, в отличие от Ваших, всегда осмысленных, "сравнениях СУБД". Я не против.

Sybase IQ именно так и хранит данные - по столбцам. Если стобец пустой, или там "сильноразряженный", то он практически ничего на диске не занимает, независимо от числа строк в таблице. Более того - если в таблице миллион строк километровой длины, но в строках хранится всего десять - сто - тысяча уникальных значений, то эти значения будут закодированы и храниться будут толко пара байт (и образцы строк). Такая вот звездообразная схема реализована "унутре думателя".
При всем этом IQ является вполне себе реляционной СУБД (а не кашей какой-то), и даже Transact SQL понимает.
...
Рейтинг: 0 / 0
26.07.2007, 01:08
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34684391
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
Bogdanov Andrey БредМожет чего не правильно настроил:

В таблице 1000 колонок типа Integer.
1 000 000 записей, и только в одной колонке каждой записи записал значение=1.

SQL Server 2005 - 17.2 Gb
Cache 5.2 - 17 Mb

И, если кто может, скажите какой результат в Oracle?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
SQL> create table EmptyTable
   2   (RecordId integer,
   3   ColId integer,
   4   CalValue integer)
   5   storage(initial 1M next  0 );

Table created.

SQL> insert into EmptyTable(RecordId,ColId,CalValue)
   2   select n, 1000 , 1  from (select rownum n from dual connect by level <  1000001 );

 1000000  rows created.

SQL> select bytes/ 1024 / 1024  from dba_segments where segment_name=upper('EmptyTable');

BYTES/ 1024 / 1024 
---------------
              18

То есть 18 Mb. Это слегка завышенная цифра, так как место выделяется экстентами. Без увеличения размера в эту табличку можно добавить еще около ста тысяч записей.

А где тут 1000 колонок типа int ?
...
Рейтинг: 0 / 0
26.07.2007, 01:11
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34684393
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
Выбегалло Bogdanov Andrey БредМожет чего не правильно настроил:

В таблице 1000 колонок типа Integer.
1 000 000 записей, и только в одной колонке каждой записи записал значение=1.

SQL Server 2005 - 17.2 Gb
Cache 5.2 - 17 Mb

И, если кто может, скажите какой результат в Oracle?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
SQL> create table EmptyTable
   2   (RecordId integer,
   3   ColId integer,
   4   CalValue integer)
   5   storage(initial 1M next  0 );

Table created.

SQL> insert into EmptyTable(RecordId,ColId,CalValue)
   2   select n, 1000 , 1  from (select rownum n from dual connect by level <  1000001 );

 1000000  rows created.

SQL> select bytes/ 1024 / 1024  from dba_segments where segment_name=upper('EmptyTable');

BYTES/ 1024 / 1024 
---------------
              18

То есть 18 Mb. Это слегка завышенная цифра, так как место выделяется экстентами. Без увеличения размера в эту табличку можно добавить еще около ста тысяч записей.

А где тут 1000 колонок типа int ?

А, пардон, сразу не просек. Ну да, ну да - это та самая схема хранения, в которой элементарный запрос надо полдня продумывать, а потом сервер полдня джойны хреначит. Знакомая штука.
...
Рейтинг: 0 / 0
26.07.2007, 01:15
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34684640
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Выбегалло
А где тут 1000 колонок типа int ?
А где у Cashe 1000 колонок? Там вообще нет ни одной колонки.

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

Время продумывания и время выполнения зависит в основном от умственных способностей продумывающего, а не от сервера и т.п.
...
Рейтинг: 0 / 0
26.07.2007, 09:03
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34684959
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
pavelvp БредТам разные способы хранения, и не совсем понятно о чем Вы говорите. В любом случае там не нужно бороться с разреженностью - количество колонок в таблице не ограничено. Конечно не ограничено. Ведь там нет ни того, ни другого. Ограничение на размер "ключа" всё же есть.

Где "там"? Я не так давно познакомился с Cache, но успел увидеть три СУБД. И во всех были таблицы и колонки. Может это у Вас ревность? Потому что "там" много чего есть. Лучше опубликуйте результат бессмысленного теста для Линтер, и сравните его, конечно же, с SQL Server.
...
Рейтинг: 0 / 0
26.07.2007, 10:42
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34684975
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
SergSuper БредВы мне предлагаете сделать количество колонок в таблице не ограниченным, и не занимать место под несуществующие данные в SQL Server ??? Я этого сделать не могу.
Я ничего не предлагаю, я просто объясняю что структура данных в Cache эквивалентна таблице с двумя полями. Снимаю шляпу перед маркетологами Cache, которые для этого сумели придумать красивое название "разряженные массивы"

Не правильно объясняете - не знаю - от незнания или умышленно? Структура данных в Cache эквивалентна, помимо прочего, таблице с неограниченным числом полей. А маркетинг у Cache просто нулевой. И у меня создается ощущение, что это совсем не беспокоит Intersystems.
...
Рейтинг: 0 / 0
26.07.2007, 10:45
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34684993
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
hvlad БредБольшое спасибо. Пусть и бессмысленный, но результат:

В таблице 1000 колонок типа Integer.
1 000 000 записей, и только в последней колонке каждой записи записали значение=1.

SQL Server 2005 - 17.2 Gb
Cache 5.2 - 17 Mb
Oracle ??? - 1.11 Gb

А разве любой из таких вот "отдельных результатов" нельзя назвать бессмысленным?
Наверное нужно закрывать этот раздел на форуме.Гм. Не знаю - зачем я это делал :), но вот результаты Firebird
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
execute block returns (s varchar( 20080 ))
as
declare i int;
begin
  s = 'create table t (id int)';
  execute statement :s;
  suspend;

  s = '';
  i =  1 ;
  while (i <  1000 ) do
  begin
    if (char_length(s) <  20000  or s = '')
    then begin
      if (s = '')
      then s = 'alter table t add col' || i || ' int';
      else s = s || ', add col' || i || ' int';
    end
    else begin
      execute statement :s;
      suspend;

      s = '';
    end

    i = i +  1 ;
  end

  if (s <> '')
  then begin
    execute statement :s;
    suspend;
  end
end;
commit;
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
execute block as
declare i int =  0 ;
begin
  while (i <  1000000 ) do
  begin
    insert into t (id) values (:i);
    i = i +  1 ;
  end
end
commit;
Сразу после этого :
Код: plaintext
1.
Data pages: 14085, data page slots: 14085, average fill: 79%
Average record length: 73.93, total records: 1000000
Размер страницы 8К, т.е. имеем 112680КБ или 110МБ

Заносим 1 в последнюю колонку :
Код: plaintext
update t set col999 =  1
Статистика :
Код: plaintext
1.
    Average record length: 77.26, total records: 1000000 
    Data pages: 16796, data page slots: 16796, average fill: 98%
Т.е. 134368КБ или 131МБ

Здорово! Если эта штука реляционная, то по этому тесту она оказалась лидером среди РСУБД. Правда в Oracle считают (после интеграции экспресса, "древовидных даблиц" и др. фишек), что Oracle уже не реляционная. Не удивительно, что у нее результат бессмысленного теста получше, чем у SQL Server.
...
Рейтинг: 0 / 0
26.07.2007, 10:51
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685015
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Bogdanov Andrey БредМожет чего не правильно настроил:

В таблице 1000 колонок типа Integer.
1 000 000 записей, и только в одной колонке каждой записи записал значение=1.

SQL Server 2005 - 17.2 Gb
Cache 5.2 - 17 Mb

И, если кто может, скажите какой результат в Oracle?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
SQL> create table EmptyTable
   2   (RecordId integer,
   3   ColId integer,
   4   CalValue integer)
   5   storage(initial 1M next  0 );

Table created.

SQL> insert into EmptyTable(RecordId,ColId,CalValue)
   2   select n, 1000 , 1  from (select rownum n from dual connect by level <  1000001 );

 1000000  rows created.

SQL> select bytes/ 1024 / 1024  from dba_segments where segment_name=upper('EmptyTable');

BYTES/ 1024 / 1024 
---------------
              18

То есть 18 Mb. Это слегка завышенная цифра, так как место выделяется экстентами. Без увеличения размера в эту табличку можно добавить еще около ста тысяч записей.

Вам не кажется, что Вы изобрели какой-то другой тест?
...
Рейтинг: 0 / 0
26.07.2007, 10:59
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685019
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Выбегалло Бред говорил про базы данных, кажется. А именно про хранение "сильно разреженных таблиц", в которых иногда есть потребность. Но пусть это будет совершенно бессмысленным, в отличие от Ваших, всегда осмысленных, "сравнениях СУБД". Я не против.

Sybase IQ именно так и хранит данные - по столбцам. Если стобец пустой, или там "сильноразряженный", то он практически ничего на диске не занимает, независимо от числа строк в таблице. Более того - если в таблице миллион строк километровой длины, но в строках хранится всего десять - сто - тысяча уникальных значений, то эти значения будут закодированы и храниться будут толко пара байт (и образцы строк). Такая вот звездообразная схема реализована "унутре думателя".
При всем этом IQ является вполне себе реляционной СУБД (а не кашей какой-то), и даже Transact SQL понимает.

Жаль что нет конкретного результата, но объяснение впечатляет. Спасибо!
...
Рейтинг: 0 / 0
26.07.2007, 11:01
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685030
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Выбегалло Выбегалло Bogdanov Andrey БредМожет чего не правильно настроил:

В таблице 1000 колонок типа Integer.
1 000 000 записей, и только в одной колонке каждой записи записал значение=1.

SQL Server 2005 - 17.2 Gb
Cache 5.2 - 17 Mb

И, если кто может, скажите какой результат в Oracle?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
SQL> create table EmptyTable
   2   (RecordId integer,
   3   ColId integer,
   4   CalValue integer)
   5   storage(initial 1M next  0 );

Table created.

SQL> insert into EmptyTable(RecordId,ColId,CalValue)
   2   select n, 1000 , 1  from (select rownum n from dual connect by level <  1000001 );

 1000000  rows created.

SQL> select bytes/ 1024 / 1024  from dba_segments where segment_name=upper('EmptyTable');

BYTES/ 1024 / 1024 
---------------
              18

То есть 18 Mb. Это слегка завышенная цифра, так как место выделяется экстентами. Без увеличения размера в эту табличку можно добавить еще около ста тысяч записей.

А где тут 1000 колонок типа int ?

А, пардон, сразу не просек. Ну да, ну да - это та самая схема хранения, в которой элементарный запрос надо полдня продумывать, а потом сервер полдня джойны хреначит. Знакомая штука.

Да, кажется об этой реляционной "фишке-подмене" я говорил в одном из сообщений.
...
Рейтинг: 0 / 0
26.07.2007, 11:04
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685041
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Bogdanov Andrey Выбегалло
А где тут 1000 колонок типа int ?
А где у Cashe 1000 колонок? Там вообще нет ни одной колонки.


Это еще одна форма сообщения о бессмысленности. Точнее даже намек на наглую ложь. Типа 17 Мб с неба свалились.
...
Рейтинг: 0 / 0
26.07.2007, 11:07
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685120
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Бред Bogdanov Andrey
То есть 18 Mb. Это слегка завышенная цифра, так как место выделяется экстентами. Без увеличения размера в эту табличку можно добавить еще около ста тысяч записей.

Вам не кажется, что Вы изобрели какой-то другой тест?
Почему другой? Что в нем не так? Какую функциональность, подразумевавшуюся вашим тестом это тест не покрывает?
Кстати, свой тест на Cache вы вообще не показали.
...
Рейтинг: 0 / 0
26.07.2007, 11:27
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685166
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
Бред SergSuper БредВы мне предлагаете сделать количество колонок в таблице не ограниченным, и не занимать место под несуществующие данные в SQL Server ??? Я этого сделать не могу.
Я ничего не предлагаю, я просто объясняю что структура данных в Cache эквивалентна таблице с двумя полями. Снимаю шляпу перед маркетологами Cache, которые для этого сумели придумать красивое название "разряженные массивы"

Не правильно объясняете - не знаю - от незнания или умышленно? Структура данных в Cache эквивалентна, помимо прочего, таблице с неограниченным числом полей. А маркетинг у Cache просто нулевой. И у меня создается ощущение, что это совсем не беспокоит Intersystems.
Да Вы ж не первый кто с этим пытался спорить. Опишите любую структуру, которую Вы храните на Cache, я её засуну в таблицу из двух полей.

БредЗдорово! Если эта штука реляционная, то по этому тесту она оказалась лидером среди РСУБД. Правда в Oracle считают (после интеграции экспресса, "древовидных даблиц" и др. фишек), что Oracle уже не реляционная. Не удивительно, что у нее результат бессмысленного теста получше, чем у SQL Server.
Простите, а у Вас критерий лидерства - объём занимаемой базой на диске?

И еще - если Вы кидаетесь такими словами как "наглая ложь" - потрудитесь это как-то обосновывать
...
Рейтинг: 0 / 0
26.07.2007, 11:34
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685201
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Bogdanov Andrey Бред Bogdanov Andrey
То есть 18 Mb. Это слегка завышенная цифра, так как место выделяется экстентами. Без увеличения размера в эту табличку можно добавить еще около ста тысяч записей.

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

Потому что другой. Как еще объяснить? Я про таблицу из трех колонок уже говорил.
И про запросы Вам уже говорили.
...
Рейтинг: 0 / 0
26.07.2007, 11:43
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685224
nig_AM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nig_AM
Участник
скажу один вещь.
пусть летают в космос пассажиры
пусть программы пишут все пользователи-непрофессионалы

а непрофессионалалы хирурги непрофессионально режут топикстартера..имхо
...
Рейтинг: 0 / 0
26.07.2007, 11:48
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685235
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
SergSuper Бред SergSuper БредВы мне предлагаете сделать количество колонок в таблице не ограниченным, и не занимать место под несуществующие данные в SQL Server ??? Я этого сделать не могу.
Я ничего не предлагаю, я просто объясняю что структура данных в Cache эквивалентна таблице с двумя полями. Снимаю шляпу перед маркетологами Cache, которые для этого сумели придумать красивое название "разряженные массивы"

Не правильно объясняете - не знаю - от незнания или умышленно? Структура данных в Cache эквивалентна, помимо прочего, таблице с неограниченным числом полей. А маркетинг у Cache просто нулевой. И у меня создается ощущение, что это совсем не беспокоит Intersystems.
Да Вы ж не первый кто с этим пытался спорить. Опишите любую структуру, которую Вы храните на Cache, я её засуну в таблицу из двух полей.

БредЗдорово! Если эта штука реляционная, то по этому тесту она оказалась лидером среди РСУБД. Правда в Oracle считают (после интеграции экспресса, "древовидных даблиц" и др. фишек), что Oracle уже не реляционная. Не удивительно, что у нее результат бессмысленного теста получше, чем у SQL Server.
Простите, а у Вас критерий лидерства - объём занимаемой базой на диске?

И еще - если Вы кидаетесь такими словами как "наглая ложь" - потрудитесь это как-то обосновывать

Не знаю с кем Вы там спорили. У каждой из этих тысяч колонок свой тип, свой смысл, свои ограничения целостности. Хватит уже трепаться, а? Bogdanov Andrey уже все что можно засунул. Вот с ним и соревнуйтесь.

Позвольте мне не обосновывать, что я не нагло вру. Если Вам удобно так считать - считайте на здоровье.
...
Рейтинг: 0 / 0
26.07.2007, 11:50
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685269
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
nig_AMскажу один вещь.
пусть летают в космос пассажиры
пусть программы пишут все пользователи-непрофессионалы

а непрофессионалалы хирурги непрофессионально режут топикстартера..имхо

Уточню. "Весь цивилизованный мир" (и я в том числе) работает на SQL Server. Кто-то не профессионально (17.2Гб), кто-то профессионально (4 Гб), кто-то профессионально пудрит сам себе мозги (18 Мб). Но хочется иногда понять где ты находишься вместе со всем цивилизованным миром. И выясняется, что лучше бы не понимать. Потому что находишься ты в нехорошем месте.
...
Рейтинг: 0 / 0
26.07.2007, 11:59
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685297
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
SergSuper БредЗдорово! Если эта штука реляционная, то по этому тесту она оказалась лидером среди РСУБД. Правда в Oracle считают (после интеграции экспресса, "древовидных даблиц" и др. фишек), что Oracle уже не реляционная. Не удивительно, что у нее результат бессмысленного теста получше, чем у SQL Server.
Простите, а у Вас критерий лидерства - объём занимаемой базой на диске?


ПО ЭТОМУ ТЕСТУ . Какой еще должен быть критерий ПО ЭТОМУ ТЕСТУ ?
...
Рейтинг: 0 / 0
26.07.2007, 12:04
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685321
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
БредУточню. "Весь цивилизованный мир" (и я в том числе) работает на SQL Server.
Какое счастье, что до сих пор остаются не тронутые цивилизацией уголки :)
...
Рейтинг: 0 / 0
26.07.2007, 12:11
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685348
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
БредПозвольте мне не обосновывать, что я не нагло вру. Если Вам удобно так считать - считайте на здоровье.
Уважаемый, Вы других обвиняете во лжи без всяких обоснований. Я считаю это оскорблением и как модератор буду такие посты тереть. Считайте это официальным предупреждением
...
Рейтинг: 0 / 0
26.07.2007, 12:19
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685453
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer БредУточню. "Весь цивилизованный мир" (и я в том числе) работает на SQL Server.
Какое счастье, что до сих пор остаются не тронутые цивилизацией уголки :)

Не могу не согласиться. К Oracle меня тянет...
...
Рейтинг: 0 / 0
26.07.2007, 12:38
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685462
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
SergSuper БредПозвольте мне не обосновывать, что я не нагло вру. Если Вам удобно так считать - считайте на здоровье.
Уважаемый, Вы других обвиняете во лжи без всяких обоснований. Я считаю это оскорблением и как модератор буду такие посты тереть. Считайте это официальным предупреждением

Уважаемый, я всего лишь сказал, что меня обвиняют в наглой лжи. А Вы все нагло переврали, нагло пользуясь возможностью тереть.
...
Рейтинг: 0 / 0
26.07.2007, 12:40
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685466
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
Бред
Не могу не согласиться. К Oracle меня тянет...
но потянет ли оракл такой Бред ... :) ?
...
Рейтинг: 0 / 0
26.07.2007, 12:41
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685532
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Yo.! Бред
Не могу не согласиться. К Oracle меня тянет...
но потянет ли оракл такой Бред ... :) ?

Похоже Ваш вариант теста показал совсем уж не удовлетворительный результат. Пора, пора друзья переходить на личности.
...
Рейтинг: 0 / 0
26.07.2007, 12:55
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34685565
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Бред Bogdanov Andrey Выбегалло
А где тут 1000 колонок типа int ?
А где у Cashe 1000 колонок? Там вообще нет ни одной колонки.


Это еще одна форма сообщения о бессмысленности. Точнее даже намек на наглую ложь. Типа 17 Мб с неба свалились.

Из последующей перепалки с модератором я понял, что Бред воспринял мою фразу как обвинение во лжи.
Хочу уверить, что я и не пытался поставить под сомнение результаты "Бредовского" теста. Особенно учитывая, что достиг точно таких же результатов.
Я просто считаю, что в Cache вообще нет колонок в моем понимании. Правда если быть уж совсем точным, то термин "колонка", как мне кажется, вообще отсутствуетв теории баз данных. Как реляционных, так и "постреляционных" (а кстати, где можно прочитать про теорию постреляционных баз данных?)
Может быть я ошибаюсь и такой термин есть? Если да, то сообщите мне его определение, объясните что в Cache подходит под это определение. И тогда я смогу показать где в моем тесте 1000 колонок.
...
Рейтинг: 0 / 0
26.07.2007, 13:02
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34686192
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Bogdanov Andrey Бред Bogdanov Andrey Выбегалло
А где тут 1000 колонок типа int ?
А где у Cashe 1000 колонок? Там вообще нет ни одной колонки.


Это еще одна форма сообщения о бессмысленности. Точнее даже намек на наглую ложь. Типа 17 Мб с неба свалились.

Из последующей перепалки с модератором я понял, что Бред воспринял мою фразу как обвинение во лжи.
Хочу уверить, что я и не пытался поставить под сомнение результаты "Бредовского" теста. Особенно учитывая, что достиг точно таких же результатов.
Я просто считаю, что в Cache вообще нет колонок в моем понимании. Правда если быть уж совсем точным, то термин "колонка", как мне кажется, вообще отсутствуетв теории баз данных. Как реляционных, так и "постреляционных" (а кстати, где можно прочитать про теорию постреляционных баз данных?)
Может быть я ошибаюсь и такой термин есть? Если да, то сообщите мне его определение, объясните что в Cache подходит под это определение. И тогда я смогу показать где в моем тесте 1000 колонок.

Спасибо, я удовлетворен Вашим объяснением.
Я уже сказал, отвечая pavelvp, что видел бегло пока три СУБД в Cache. И во всех есть таблицы и колонки (просто называется это другими словами, так же как есть отношения и атрибуты в реляционной теории). Пусть поправят лучше знающие, если в чем-то ошибусь. Родная Cache Objects имеет в базовом способе хранения ограничение на число колонок в таблице, просто из-за ограничения на длину записи 32К. Говорится, что можно как угодно переопределять способ хранения данных, но как при этом обеспечивется концептуальная целостность (запросы и т.д.) понятия не имею. Больше мне понравились модели данных и их хранение (не "переопределяемое") в q.Word и X.Magic. В частности, как раз в последней нет ограничений на число колонок в таблице.
И именно такую схему я и использовал в тесте.
...
Рейтинг: 0 / 0
26.07.2007, 15:03
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34686554
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
БредГде "там"? Я не так давно познакомился с Cache, но успел увидеть три СУБД. И во всех были таблицы и колонки. Может это у Вас ревность? Потому что "там" много чего есть.
:-)))
"Ты суслика видишь? Нет. И я не вижу. А он есть!" :-)

Лучше опубликуйте результат бессмысленного теста для Линтер, и сравните его, конечно же, с SQL Server. Если Вы напряжёте свою память, Андрей Леонидович, то наверняка вспомните, что похожие сравнения я уже проводил и публиковал здесь года два назад для ЛИНТЕР, MSSQL и Cache.
Это в том же топике о котором SergSuper чуть выше упоминал.
...
Рейтинг: 0 / 0
26.07.2007, 16:21
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34686619
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
pavelvp Если Вы напряжёте свою память, Андрей Леонидович, то наверняка вспомните...
ЧАЛ из Латвии писал, а этот IP московский
Да и стилистика немного другая. Я всё-таки склоняюсь что не он
...
Рейтинг: 0 / 0
26.07.2007, 16:35
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34686623
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
pavelvp БредГде "там"? Я не так давно познакомился с Cache, но успел увидеть три СУБД. И во всех были таблицы и колонки. Может это у Вас ревность? Потому что "там" много чего есть.
:-)))
"Ты суслика видишь? Нет. И я не вижу. А он есть!" :-)

Лучше опубликуйте результат бессмысленного теста для Линтер, и сравните его, конечно же, с SQL Server. Если Вы напряжёте свою память, Андрей Леонидович, то наверняка вспомните, что похожие сравнения я уже проводил и публиковал здесь года два назад для ЛИНТЕР, MSSQL и Cache.
Это в том же топике о котором SergSuper чуть выше упоминал.

Опа! Даже не знаю радоваться или говорить "сам ты Андрей Леонидович".
Топик посмотрел. Там этого нет. Слишком много неправды у Вас в одном сообщении.
Суслик - это этот Андрей Леонидович что ли?
...
Рейтинг: 0 / 0
26.07.2007, 16:36
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34686629
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
SergSuper pavelvp Если Вы напряжёте свою память, Андрей Леонидович, то наверняка вспомните...
ЧАЛ из Латвии писал, а этот IP московский
Да и стилистика немного другая. Я всё-таки склоняюсь что не он

Нашли хорошую подтему для "разреженных таблиц".
...
Рейтинг: 0 / 0
26.07.2007, 16:37
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34686652
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, SergSuper!
Ты пишешь:

SergSuperS> ЧАЛ из Латвии писалошибаешься.

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

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

SergSuperS> ЧАЛ из Латвии писалошибаешься.

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

Posted via ActualForum NNTP Server 1.4

Эта подтема более конструктивна. Разберитесь в ней поглубже, господа!
...
Рейтинг: 0 / 0
26.07.2007, 16:47
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34686753
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
Бред
Спасибо, я удовлетворен Вашим объяснением.
Я уже сказал, отвечая pavelvp, что видел бегло пока три СУБД в Cache. И во всех есть таблицы и колонки (просто называется это другими словами, так же как есть отношения и атрибуты в реляционной теории). Пусть поправят лучше знающие, если в чем-то ошибусь. Родная Cache Objects имеет в базовом способе хранения ограничение на число колонок в таблице, просто из-за ограничения на длину записи 32К. Говорится, что можно как угодно переопределять способ хранения данных, но как при этом обеспечивется концептуальная целостность (запросы и т.д.) понятия не имею. Больше мне понравились модели данных и их хранение (не "переопределяемое") в q.Word и X.Magic. В частности, как раз в последней нет ограничений на число колонок в таблице.
И именно такую схему я и использовал в тесте.
Я не хочу ругать Cache или или хвалить Oracle. Своим постом я хотел показать, что простое сравнение объема занимаемого данными - задача бессмысленная в отрыве от решаемой задачи и от конкретной прикладной постановки. Да, способы организации информации в разных СУБД - разные. Но при любом способе хранения можно добиться минимизации объема. И кстати, предлагаемый мною вариант очень часто используется (к сожалению и где надо и где не надо - честно скажу, что чаще, где не надо).
...
Рейтинг: 0 / 0
26.07.2007, 17:00
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34686855
Andreww
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andreww
Участник
Очень подходящий ник :)Эта подтема более конструктивна. Разберитесь в ней поглубже, господа!

ЧАЛ, голубчик, неглупые люди разобрались уже во всём и без нас :)

Психологическая энциклопедия ШИЗОФАЗИЯ - (шизо + греч. phasis - речь) [Kraepelin E., 1913]. Своеобразное проявление мыслительно-речевых расстройств при шизофрении. Первоначально выделялась как особая форма шизофрении, при которой резко выраженная разорванность и совершенно непонятная речь контрастируют с внешней упорядоченностью, известной доступностью и относительной интеллектуальной и аффективной сохранностью больных. Характерна повышенная речевая активность, речевой напор. Выражен симптом монолога, характеризующийся речевой неистощимостью и отсутствием потребности в собеседнике. В настоящее время рассматривается как этап течения параноидной шизофрении [Вроно М.Ш., 1959]. По A. Kronfeld [1940], Ш. близка к разорванности, общим для них является важная роль в формировании клинической картины психомоторно-кататонических динамизмов. Описаны случаи, когда Ш. проявлялась только в письменной речи (шизография) [Levi-Valensy J., Migault P., Lacan J., 1931].


Тратить время на всяких фриков - нет уж увольте :)
...
Рейтинг: 0 / 0
26.07.2007, 17:20
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34686909
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pavelvp
Участник
БредСлишком много неправды у Вас в одном сообщении.Вот и меня в лгунов записали :-(
...
Рейтинг: 0 / 0
26.07.2007, 17:31
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34687500
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
Bogdanov Andrey Выбегалло
А где тут 1000 колонок типа int ?
А где у Cashe 1000 колонок? Там вообще нет ни одной колонки.

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

Время продумывания и время выполнения зависит в основном от умственных способностей продумывающего, а не от сервера и т.п.

А нарисуйте мне SELECT A,B,C from table1 WHERE id = 1 and datastamp = '2007-07-26' ?
У меня заняло 30 секунд запрос напечатать - сколько у вас займет ?
...
Рейтинг: 0 / 0
26.07.2007, 22:54
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34687533
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
Выбегалло Bogdanov Andrey Выбегалло
А где тут 1000 колонок типа int ?
А где у Cashe 1000 колонок? Там вообще нет ни одной колонки.

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

Время продумывания и время выполнения зависит в основном от умственных способностей продумывающего, а не от сервера и т.п.

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

И, кстати, вы как собираетесь char-ы с int-ами хранить - кошерно, в отдельных таблицах, или все в varchar-ы преобразовывать будете ?
...
Рейтинг: 0 / 0
26.07.2007, 23:26
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34687805
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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". А в реальной жизни я буду выбирать способ хранения наиболее адекватный задаче.
...
Рейтинг: 0 / 0
27.07.2007, 09:34
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34688176
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
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.



Maybe

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select max(A), max(B), max(C)
from
(
select decode(ColId, 1 ,ColValue,null) A, decode(ColId, 2 ,ColValue,null) B, decode(ColId, 3 ,ColValue,null) C, RecordId 
from table1 a
where exists
      ( select  1  from table1 b where b.RecordId = a.RecordId and b.ColId =  4  and b.ColValue =  1 )

) tmpr
group by RecordId 

;

Так, наверно, более подобно селекту из вопроса?

ColId = 4 для колонки id.

Кстати, Андрей, как я понял в исходном селекте подразумевалось, что id не уникальны, иначе второе условие бессмыслено.
...
Рейтинг: 0 / 0
27.07.2007, 11:12
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34688695
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Bogdanov Andrey Бред
Спасибо, я удовлетворен Вашим объяснением.
Я уже сказал, отвечая pavelvp, что видел бегло пока три СУБД в Cache. И во всех есть таблицы и колонки (просто называется это другими словами, так же как есть отношения и атрибуты в реляционной теории). Пусть поправят лучше знающие, если в чем-то ошибусь. Родная Cache Objects имеет в базовом способе хранения ограничение на число колонок в таблице, просто из-за ограничения на длину записи 32К. Говорится, что можно как угодно переопределять способ хранения данных, но как при этом обеспечивется концептуальная целостность (запросы и т.д.) понятия не имею. Больше мне понравились модели данных и их хранение (не "переопределяемое") в q.Word и X.Magic. В частности, как раз в последней нет ограничений на число колонок в таблице.
И именно такую схему я и использовал в тесте.
Я не хочу ругать Cache или или хвалить Oracle. Своим постом я хотел показать, что простое сравнение объема занимаемого данными - задача бессмысленная в отрыве от решаемой задачи и от конкретной прикладной постановки. Да, способы организации информации в разных СУБД - разные. Но при любом способе хранения можно добиться минимизации объема. И кстати, предлагаемый мною вариант очень часто используется (к сожалению и где надо и где не надо - честно скажу, что чаще, где не надо).

А я просто сравниваю, потому что раздел так называется. Я тоже не ругаю и не хвалю, а привожу результат. Еще раз: у этих колонок могут быть свои ограничения целостности, имена (смысл). Именно Ваш способ и делает тест бессмысленным. Результат Oracle: 1.11 Гб. Я его не ругаю, и не хвалю.
...
Рейтинг: 0 / 0
27.07.2007, 12:55
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34688709
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Andreww Очень подходящий ник :)Эта подтема более конструктивна. Разберитесь в ней поглубже, господа!

ЧАЛ, голубчик, неглупые люди разобрались уже во всём и без нас :)

Психологическая энциклопедия ШИЗОФАЗИЯ - (шизо + греч. phasis - речь) [Kraepelin E., 1913]. Своеобразное проявление мыслительно-речевых расстройств при шизофрении. Первоначально выделялась как особая форма шизофрении, при которой резко выраженная разорванность и совершенно непонятная речь контрастируют с внешней упорядоченностью, известной доступностью и относительной интеллектуальной и аффективной сохранностью больных. Характерна повышенная речевая активность, речевой напор. Выражен симптом монолога, характеризующийся речевой неистощимостью и отсутствием потребности в собеседнике. В настоящее время рассматривается как этап течения параноидной шизофрении [Вроно М.Ш., 1959]. По A. Kronfeld [1940], Ш. близка к разорванности, общим для них является важная роль в формировании клинической картины психомоторно-кататонических динамизмов. Описаны случаи, когда Ш. проявлялась только в письменной речи (шизография) [Levi-Valensy J., Migault P., Lacan J., 1931].


Тратить время на всяких фриков - нет уж увольте :)

Люди, может кто может попросить чала как-то прореагировать. А то люди как на иголках: "нет уж увольте", а сами с головой погрузились в тему, несчастные.
...
Рейтинг: 0 / 0
27.07.2007, 12:58
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34689278
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
БредЛюди, может кто может попросить чала как-то прореагировать. А то люди как на иголках: "нет уж увольте", а сами с головой погрузились в тему, несчастные.

Вот Вы и попросите :) Вам ведь, наверное сподручнее
...
Рейтинг: 0 / 0
27.07.2007, 14:47
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34689388
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Gluk (Kazan) БредЛюди, может кто может попросить чала как-то прореагировать. А то люди как на иголках: "нет уж увольте", а сами с головой погрузились в тему, несчастные.

Вот Вы и попросите :) Вам ведь, наверное сподручнее

А у Вас какой-то другой результат получился?
Вы, уважаемый Сергей Валентинович, вчера при очной встрече говорили, что опубликуете свой результат. А вместо этого тоже переключились на воспоминания о чале. Кстати, я считаю, что Вам сподручнее, все-таки, в соседних зданиях сидите.
...
Рейтинг: 0 / 0
27.07.2007, 15:08
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34689548
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
Вы меня с кем то определенно путаете, Уважаемый Коллега
Валентинович - это мой сын (и не Сергей, а Дмитрий, что характерно)
...
Рейтинг: 0 / 0
27.07.2007, 15:46
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34689605
Bogdanov Andrey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bogdanov Andrey
Участник
БредА я просто сравниваю, потому что раздел так называется. Я тоже не ругаю и не хвалю, а привожу результат. Еще раз: у этих колонок могут быть свои ограничения целостности, имена (смысл). Именно Ваш способ и делает тест бессмысленным. Результат Oracle: 1.11 Гб. Я его не ругаю, и не хвалю.
Мне как раз кажется, что ваше сравнение совершенно бессмысленно. Вы взяли некий объект в Oracle и некий объект в Cache почему-то решили, что это однородные объекты и решили сравнить их размер. С таким же успехом можно сказать, что у Эйфелевой башни 300 метров, а у великой китайской стены - 6 миллионов метров (могу ошибиться с цифрами). Это сравнение ни о чем. Вот если вы возьмете некую приклдадную задачу, то можно сравнивать ее реализации.
Вы можете сказать, что взяли вот задачу хранения разреженных массивов (осталось только строго формализовать ее) и сравнили. Но заметим, что при этом вы сравнили не СУБД, а две ВАШИХ реализации этой задачи. Как только я предложил другую реализацию вы начали навешивать дополнительные требования и ограничения.
...
Рейтинг: 0 / 0
27.07.2007, 15:58
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34689833
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Bogdanov AndreyС таким же успехом можно сказать, что у Эйфелевой башни 300 метров, а у великой китайской стены - 6 миллионов метров
Браво. Великолепная аналогия, и по точности, и по образности.
...
Рейтинг: 0 / 0
27.07.2007, 16:50
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690248
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Gluk (Kazan)Вы меня с кем то определенно путаете, Уважаемый Коллега
Валентинович - это мой сын (и не Сергей, а Дмитрий, что характерно)

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

Вам это именно кажется. Я взял два абсолютно однородных объекта с одинаковой логической структурой , и посмотрел на разницу на физическом уровне. Это настолько очевидно, что непонятно что же Вам там кажется до сих пор? Далее, см. про типы, ограничения целостности и т.д. при переходе к конкретным задачам. О Вашей реализации я сказал ДО ТОГО КАК ВЫ ЕЕ ОПУБЛИКОВАЛИ, заметьте. И именно она делает тест бессмысленным. Вы сделали другой тест. Почему? У меня только одно объяснение: Вас почему-то задели 1.11 Гб (ума не приложу почему; как-будто это единственный минус Oracle). Никаких других объяснений не соглашаться с результатом, полученным Вашим коллегой без умышленного искажения логической структуры данных, я не вижу.
...
Рейтинг: 0 / 0
27.07.2007, 19:42
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690262
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer Bogdanov AndreyС таким же успехом можно сказать, что у Эйфелевой башни 300 метров, а у великой китайской стены - 6 миллионов метров
Браво. Великолепная аналогия, и по точности, и по образности.

Пальцем в небо, как всегда.
...
Рейтинг: 0 / 0
27.07.2007, 19:43
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690264
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Бред
Вы не в первый раз выдаете фразу, достойную стать Вашей автоподписью.
...
Рейтинг: 0 / 0
27.07.2007, 19:44
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690270
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer Bogdanov AndreyС таким же успехом можно сказать, что у Эйфелевой башни 300 метров, а у великой китайской стены - 6 миллионов метров
Браво. Великолепная аналогия, и по точности, и по образности.

Пальцем в небо, как всегда. И я это четко объяснил. По существу обсуждаемого вопроса.
...
Рейтинг: 0 / 0
27.07.2007, 19:50
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690296
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
БредИ я это четко объяснил. По существу обсуждаемого вопроса.
По существу.

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

То, что заданный Вами вопрос бессмысленен, я объяснил очень давно. С тех пор забавно, конечно, наблюдать, но не более того.

Конкретно сейчас Вы делаете одну детскую ошибку: полагаете, что существует однозначное соответствие между логической и физической структурами. Вы исходите из предположения, что "есть логическая структура, которая здесь отражается вот так, здесь отражается эдак". Реально и "здесь" и "там" одна и та же логическая структура отражается уймой способов, найти оптимальное отражение - одна из задач архитектора.
...
Рейтинг: 0 / 0
27.07.2007, 20:15
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690314
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer БредИ я это четко объяснил. По существу обсуждаемого вопроса.
По существу.

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

То, что заданный Вами вопрос бессмысленен, я объяснил очень давно. С тех пор забавно, конечно, наблюдать, но не более того.

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

Это Вы, как раз, делаете ошибку, которая не дотягивает даже до детской, оставаясь младенческой: не замечаете подмену логической структуры другой логической структурой.
Ну ничего, здесь таких младенцев много. Только как-то грустно, что даже не стремитесь к пониманию предмета Вашего труда. Нелегкого младенческого труда.
...
Рейтинг: 0 / 0
27.07.2007, 20:43
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690315
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
Привет, Бред!
Ты пишешь:

БредБ> Это Вы, как раз, делаете ошибку, которая не дотягивает даже до детской,
Б> оставаясь младенческой: не замечаете подмену
Б> логической структуры другой логической структурой.
Б> Ну ничего, здесь таких младенцев много.
Б> Только как-то грустно, что даже не стремитесь к
Б> пониманию предмета Вашего труда.
Б> Нелегкого младенческого труда.о труде однофамильца(?):
http://www.sign-forum.ru/./viewtopic.php?t=5364

зы: навеяно музыкой, алкоголем и гуглем...
--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
27.07.2007, 20:47
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690350
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
БредТолько как-то грустно, что даже не стремитесь к пониманию предмета Вашего труда.
Здравствуйте, Андрей Леонидович.
...
Рейтинг: 0 / 0
27.07.2007, 21:32
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690371
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
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, возвращающий ПРАВИЛЬНЫЕ значения.
Дано :
"Просто" таблица
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


В общем, думайте еще.
...
Рейтинг: 0 / 0
27.07.2007, 22:11
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690401
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dmidek
Участник
Выбегалло

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select col1, col2, col3
from
(select min(decode(rn, 1 ,colvalue)) col1, min(decode(rn, 2 ,colvalue)) col2 ,min(decode(rn, 3 ,colvalue)) col3 ,min(decode(rn, 4 ,colvalue)) col4
from
(select row_number() over (partition by recordid order by colid) rn, e.* from emptytable e)
group by recordid)
where col4 =  1 
order by  1 , 2 , 3 
/

Код: plaintext
1.
2.
COL1 COL2 COL3 
11 21 31 
12 22 32
...
Рейтинг: 0 / 0
27.07.2007, 22:41
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690412
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
dmidek Выбегалло

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select col1, col2, col3
from
(select min(decode(rn, 1 ,colvalue)) col1, min(decode(rn, 2 ,colvalue)) col2 ,min(decode(rn, 3 ,colvalue)) col3 ,min(decode(rn, 4 ,colvalue)) col4
from
(select row_number() over (partition by recordid order by colid) rn, e.* from emptytable e)
group by recordid)
where col4 =  1 
order by  1 , 2 , 3 
/

Код: plaintext
1.
2.
COL1 COL2 COL3 
11 21 31 
12 22 32


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

И нахрена там decode ?
...
Рейтинг: 0 / 0
27.07.2007, 22:59
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690420
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dmidek
Участник
Выбегалло dmidek Выбегалло

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select col1, col2, col3
from
(select min(decode(rn, 1 ,colvalue)) col1, min(decode(rn, 2 ,colvalue)) col2 ,min(decode(rn, 3 ,colvalue)) col3 ,min(decode(rn, 4 ,colvalue)) col4
from
(select row_number() over (partition by recordid order by colid) rn, e.* from emptytable e)
group by recordid)
where col4 =  1 
order by  1 , 2 , 3 
/

Код: plaintext
1.
2.
COL1 COL2 COL3 
11 21 31 
12 22 32


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

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

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

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

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

Банальные вещи ...
...
Рейтинг: 0 / 0
27.07.2007, 23:13
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690455
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
dmidek Выбегалло dmidek Выбегалло

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select col1, col2, col3
from
(select min(decode(rn, 1 ,colvalue)) col1, min(decode(rn, 2 ,colvalue)) col2 ,min(decode(rn, 3 ,colvalue)) col3 ,min(decode(rn, 4 ,colvalue)) col4
from
(select row_number() over (partition by recordid order by colid) rn, e.* from emptytable e)
group by recordid)
where col4 =  1 
order by  1 , 2 , 3 
/

Код: plaintext
1.
2.
COL1 COL2 COL3 
11 21 31 
12 22 32


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

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

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

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

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

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

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

Ну дело таки в том, что реализация "разряженных массивов" в Oracle таки хромает. Занимается масса дискового пространства, которое никак не используется. Хуже того - при выборке приходится все это пустое место считывать с диска и кидать в память, при записи - сливать на диск. Имеете что возразить ?
При прочих равных, СУБД с более компактным хранением данных имеет преимущество в скорости выполнения запросов. Не говоря уже о стоимости дисков.
Проблема коллеги ЧАЛа в том, что он свято убежден в порочности реляционной ИДЕИ. Вот тут-то Sybase IQ и вставляет ему перо в ж... в одно место. Оказывается, можно хранить "разряженные массивы" экономно - и при этом оставаться реляционной СУБД. Все зависит от внутренней реализации.
...
Рейтинг: 0 / 0
28.07.2007, 00:39
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690467
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dmidek
Участник
Выбегалло
Ну вы таки попробуйте без извратов, на чистом SQL. Чтобы типа переносимо было.

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
select col1, col2, col3
from
(select min(decode(mod(rownum, 4 ), 1 ,colvalue)) col1, min(decode(mod(rownum, 4 ), 2 ,colvalue)) col2 ,
min(decode(mod(rownum, 4 ), 3 ,colvalue)) col3 ,min(decode(mod(rownum, 4 ), 0 ,colvalue)) col4
from
(select * from emptytable e order by recordid, colid)
group by recordid)
where col4 =  1 
order by  1 , 2 , 3 
/

Код: plaintext
1.
2.
COL1 COL2 COL3 
11 21 31 
12 22 32
...
Рейтинг: 0 / 0
28.07.2007, 00:44
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690470
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
dmidek
Это Oracle. Аналитические функции. Доступны с 8i

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

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

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

Специалист в Оракле подобен флюсу: полнота его односторонняя. (С)
Попробуйте для расширения кругозора попереносить эти "вещи" на Informix, DB2 или Sybase. Я вас уверяю, ваша склонность пользоваться "банальными вещами" резко уменьшится.
...
Рейтинг: 0 / 0
28.07.2007, 00:45
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690473
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
dmidek Выбегалло
Ну вы таки попробуйте без извратов, на чистом SQL. Чтобы типа переносимо было.

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
select col1, col2, col3
from
(select min(decode(mod(rownum, 4 ), 1 ,colvalue)) col1, min(decode(mod(rownum, 4 ), 2 ,colvalue)) col2 ,
min(decode(mod(rownum, 4 ), 3 ,colvalue)) col3 ,min(decode(mod(rownum, 4 ), 0 ,colvalue)) col4
from
(select * from emptytable e order by recordid, colid)
group by recordid)
where col4 =  1 
order by  1 , 2 , 3 
/

Код: plaintext
1.
2.
COL1 COL2 COL3 
11 21 31 
12 22 32


Вы техзадания тоже как понимаете ? Или просто незнакомы со стандартом ?
Повторяю задачу : написать SQL понимаемый большинством СУБД. Это значит, не надо использовать DECODE, ROWNUM, и MOD тоже нежелателен (без него вполне можно обойтись). Так уж и быть, SELECT from (SELECT) достаточно легко эмулировать.
...
Рейтинг: 0 / 0
28.07.2007, 00:50
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690487
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Выбегалло 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, возвращающий ПРАВИЛЬНЫЕ значения.
Дано :
"Просто" таблица
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, то получите ровно правильный результат:)
...
Рейтинг: 0 / 0
28.07.2007, 01:27
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690489
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
drev Выбегалло 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, возвращающий ПРАВИЛЬНЫЕ значения.
Дано :
"Просто" таблица
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 для не-ораклистов.
...
Рейтинг: 0 / 0
28.07.2007, 01:34
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690492
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Поверьте на слово. Или напишите функцию на Вашем диалекте, которая принимает три параметра.

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

Кстати, на мой вгляд, идея "писать на стандарте" порочна в 99% случаев.
...
Рейтинг: 0 / 0
28.07.2007, 01:45
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690494
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
drevПоверьте на слово. Или напишите функцию на Вашем диалекте, которая принимает три параметра.

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

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

Я это понимаю так, что стандарта вы не знаете, и без левых функций обойтись не можете.
Или таки можете ?
...
Рейтинг: 0 / 0
28.07.2007, 01:52
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690498
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Выбегалло drevПоверьте на слово. Или напишите функцию на Вашем диалекте, которая принимает три параметра.

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

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

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


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

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

3. я не-ораклист :) на SQL Server, например, я бы написал через case:)
...
Рейтинг: 0 / 0
28.07.2007, 02:08
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690503
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Выбегалло

Кстати, оффтопик, просто интересно. Я понимаю, Аризона, с ИТ проблемы.. Но Вам не надоело работать с "мёртвой" СУБД?
...
Рейтинг: 0 / 0
28.07.2007, 02:25
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690504
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
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 (ну любят аналитики такие схемы) - и сколько строк у вас получится ?
...
Рейтинг: 0 / 0
28.07.2007, 02:26
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690505
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
drev Выбегалло

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

С какой из трех ? IQ, Informix или DB2 ?
Слухи о смерти любой из них несколько преувеличены.
И потом, смквельсерверщиков вокруг - плюнуть некуда, ораклистов как собак, а информиксоиды - люди редкие, дорогие... :-)
...
Рейтинг: 0 / 0
28.07.2007, 02:29
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690506
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
индекс по колИД + колВелью должен сильно помочь:)


Кстати, а почему все эти вопросы ко мне?:) Я просто исправил селект:)

И совсем не считаю, что это правильный подход:))
...
Рейтинг: 0 / 0
28.07.2007, 02:33
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690507
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Выбегалло drev Выбегалло

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

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

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

Не знаю, нишевый маркет..опасно..
...
Рейтинг: 0 / 0
28.07.2007, 02:37
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690508
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
drev Выбегалло drev Выбегалло

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

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

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

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

11 лет - полет нормальный. Зато практически нет индусов, рождающихся со знанием Informix. А вот на Transact SQL, судя по их резюме, им мама колыбельные пела :-)
...
Рейтинг: 0 / 0
28.07.2007, 02:41
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690509
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Выбегалло 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 (ну любят аналитики такие схемы) - и сколько строк у вас получится ?


Кстати, селект Вы опять поломали:)
...
Рейтинг: 0 / 0
28.07.2007, 02:48
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690583
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
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 как Вы сказали.
...
Рейтинг: 0 / 0
28.07.2007, 11:31
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690599
Фотография dmidek
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dmidek
Участник
drev
Кстати, селект Вы опять поломали:)

drev, Ваш селект совершенно правилен

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select max(A), max(B), max(C)
from
(
select decode(ColId, 1 ,ColValue,null) A, decode(ColId, 2 ,ColValue,null) B, decode(ColId, 3 ,ColValue,null) 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 
;

Код: plaintext
1.
2.
MAX(A) MAX(B) MAX(C) 
11 21 31 
12 22 32

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

2Выбегалло :

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

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
RECORDID COLID COLVALUE 
1 1 11 
1 200 21 
1 300 31 
1 400 1 
2 1 12 
2 200 22 
2 300 32 
2 400 1 
3 1 12 
3 200 22 
3 300 32 
3 400 2
То есть завязываться на конкретные значения colid нельзя -
они могут быть любыми.
Продемонстрируйте, если не трудно.
Хочется насладиться мощью стандартных решений :-)
...
Рейтинг: 0 / 0
28.07.2007, 12:15
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690898
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
dmidek

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


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

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

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

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
RECORDID COLID COLVALUE 
1 1 11 
1 200 21 
1 300 31 
1 400 1 
2 1 12 
2 200 22 
2 300 32 
2 400 1 
3 1 12 
3 200 22 
3 300 32 
3 400 2
То есть завязываться на конкретные значения colid нельзя -
они могут быть любыми.
Продемонстрируйте, если не трудно.
Хочется насладиться мощью стандартных решений :-)

По-моему, у вас склероз. Это я просил изобразить селект на СТАНДАРТНОМ SQL. И даже продемонстрировал пример с CASE. Вы себя на поприще умения работать со стандартом пока никак не проявили, так что сейчас как раз подходящий момент показать крутизну.
А ваш "общий случай" не работает хотя бы потому, что вы не возвращаете четвертую колонку (ID ) - соответственно фильтр накладывать не на что.
И относительно вашего замечания про привязывания к конкретным colid - вам при SELECTе имена колонок требуются ? Ну так в "плоской форме" их заменяют colid. Отфонаря их брать нельзя, фигня получится. Что является еще одним недостатком данной модели.
...
Рейтинг: 0 / 0
29.07.2007, 01:05
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690922
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
select A, B, C
from 
(
	select 
		t1.ColValue A,
		t1.ColValue B,
		t1.ColValue C,
		t1.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 ;
...
Рейтинг: 0 / 0
29.07.2007, 04:49
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34690950
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Выбегалло dmidek

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


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



Вы их неправильно переводите:)
...
Рейтинг: 0 / 0
29.07.2007, 09:40
| Ответить | Цитировать | Написать  
Разработка СУБД
    #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
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34694030
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
SergSuper MasterZiv
SergSuper пишет:
> ЧАЛ из Латвии писал, а этот IP московский
> Да и стилистика немного другая. Я всё-таки склоняюсь что не он
>
> простите меня люди, был не прав, всё-таки это он

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

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

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

Да, настоящий дибил. Спасибо за информацию - я в других темах смотрел, когда он как зарегистрированный был. Но там тоже не лучше. А поначалу не выглядели его "мысли", как явная глупость. А теперь вот по-внимательнее почитал...
...
Рейтинг: 0 / 0
30.07.2007, 19:45
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34694047
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Бред пишет:
> Да, настоящий дибил. Спасибо за информацию - я в других темах смотрел,
> когда он как зарегистрированный был. Но там тоже не лучше. А поначалу не
> выглядели его "мысли", как явная глупость. А теперь вот по-внимательнее

Ага, а здесь ЧАЛ - это Бред, да ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
30.07.2007, 20:01
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34694066
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Yo.! Выбегалло
Да вы наперсточник, батенька.
1. DECODE - в стандарте не прописано.

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


Выбегалло
3. С какой стати DECODE должно быть известно разработчикам других платформ ?
а с какими субд вы имели дело ? DECODE есть и в db2 и в Informix , есть в клонах Postgres (Enterpisedb), наверника в mysql maxdb ...


Я думаю, Вы сами сможете назвать СУБД, которая имеет больше двух процентов рынка и не поддерживает DECODE?)
...
Рейтинг: 0 / 0
30.07.2007, 20:16
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34694095
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
drev
Я думаю, Вы сами сможете назвать СУБД, которая имеет больше двух процентов рынка и не поддерживает DECODE?)
у вас decode - аналитическая функция ?
...
Рейтинг: 0 / 0
30.07.2007, 20:41
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34694101
drev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
drev
Участник
Yo.! Выбегалло
Мне как-то глубоко покласть на ваше мнение о моей (без)грамотности, удивляет только, с какого перепугу вы решили, что оракловские расширения должны быть известны разработчикам других платформ.

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

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

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



И ? С каких пор они понимают SELECT OVER и PARTITION BY ? Нельзя ли ограничиться стандартом ?

Yo.!
Выбегалло
3. С какой стати DECODE должно быть известно разработчикам других платформ ?
а с какими субд вы имели дело ? DECODE есть и в db2 и в Informix , есть в клонах Postgres (Enterpisedb), наверника в mysql maxdb ...

Насколько я помню, вы у нас любитель MS SQL.
Сколько процентов рынка занимают MS SQL 7 и 2000 ? Есть ли в них decode ?
...
Рейтинг: 0 / 0
30.07.2007, 21:13
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34694254
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
Выбегалло
И ? С каких пор они понимают SELECT OVER и PARTITION BY ? Нельзя ли ограничиться стандартом ?

ну Sybase IQ понимает с рождения (было бы странно если бы аналитическая субд не супортила анлитические запросы).
а стандартом ограничется никак нельзя т.к. "SELECT OVER и PARTITION BY" описаны в стандарте ANSI SQL 2003. откройте ж наконец стандарт, и доку по informix и sybase iq, а то блин дожили - Yo! рассказывает апологетам, что есть и чего нет в их любимых субд.

Выбегалло
Насколько я помню, вы у нас любитель MS SQL.

ага, в некотором роде ....
...
Рейтинг: 0 / 0
30.07.2007, 23:17
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34694310
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
MasterZiv
Бред пишет:
> Да, настоящий дибил. Спасибо за информацию - я в других темах смотрел,
> когда он как зарегистрированный был. Но там тоже не лучше. А поначалу не
> выглядели его "мысли", как явная глупость. А теперь вот по-внимательнее

Ага, а здесь ЧАЛ - это Бред, да ?
Posted via ActualForum NNTP Server 1.4
Прочитали бы по ссылкам до конца - вопросов бы не было

На этом эту тему замнём, и так уже этим разборками было загажено несколько топиков
...
Рейтинг: 0 / 0
31.07.2007, 00:17
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34694342
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
Yo.! Выбегалло
И ? С каких пор они понимают SELECT OVER и PARTITION BY ? Нельзя ли ограничиться стандартом ?

ну Sybase IQ понимает с рождения (было бы странно если бы аналитическая субд не супортила анлитические запросы).


Это вы его с прямым углом спутали. И было б странно, если аналитическая субд 1999 года выпуска, полученная из купленного в 95м. Expressway, от рождения понимала стандарт 2003 года.

Yo.!а стандартом ограничется никак нельзя т.к. "SELECT OVER и PARTITION BY" описаны в стандарте ANSI SQL 2003.

Осталось дожить до момента, когда стандарт 93 года все воплотят в полном объеме - как тока это случится, так сразу я брошусь модные фичи из стандарта 2003 использовать. Все ихние рюшечки и кружева, с бубенчиками и свистульками.
А пока с задачей вполне JOIN и GROUP BY справляется.
...
Рейтинг: 0 / 0
31.07.2007, 00:58
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34696495
khl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
khl
Участник
IBM DB2: при включенной компрессии указанная таблица (1000 х 1000000) занимает 30 Мб. Расположение единиц значения не имеет.

тут
...
Рейтинг: 0 / 0
31.07.2007, 18:15
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34696669
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
khlIBM DB2: при включенной компрессии указанная таблица (1000 х 1000000) занимает 30 Мб. Расположение единиц значения не имеет.

тут
1. Не Interbase, а Firebird
2. Там 100К строк а не 1М
...
Рейтинг: 0 / 0
31.07.2007, 19:25
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34696680
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
SergSuper MasterZiv
Бред пишет:
> Да, настоящий дибил. Спасибо за информацию - я в других темах смотрел,
> когда он как зарегистрированный был. Но там тоже не лучше. А поначалу не
> выглядели его "мысли", как явная глупость. А теперь вот по-внимательнее

Ага, а здесь ЧАЛ - это Бред, да ?
Posted via ActualForum NNTP Server 1.4
Прочитали бы по ссылкам до конца - вопросов бы не было

На этом эту тему замнём, и так уже этим разборками было загажено несколько топиков

Самое смешное, если автор этого сообщения и есть модератор !? И он удалил мое сообщение приблизительно с таким, вполне корректным, содержанием (при этом не удалив это свое сообщение!):

Так Вы же и загаживаете разборками топики, потому что по существу обсуждаемых вопросов Вам никогда нечего сказать. А товарищ абсолютно прав. Здесь дибил, конечно, я. Потому что:
SQL Server - 17.2 Гб
Oracle ??? - 1.11 Гб
Cache 5.2 - 17 Мб
Я не сторонник Cache, а, скорее, поклонник Oracle, но дибил просто потому что вот такие цифры получились.
...
Рейтинг: 0 / 0
31.07.2007, 19:32
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34696715
khl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
khl
Участник
hvlad khlIBM DB2: при включенной компрессии указанная таблица (1000 х 1000000) занимает 30 Мб. Расположение единиц значения не имеет.

тут
1. Не Interbase, а Firebird
2. Там 100К строк а не 1М

Я не про IB/FB, а про DB2 фирмы IBM.
Задача ставилась про таблицу в 1000 колонок с 1 млн. строк.
...
Рейтинг: 0 / 0
31.07.2007, 19:51
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34696784
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
khl hvlad khlIBM DB2: при включенной компрессии указанная таблица (1000 х 1000000) занимает 30 Мб. Расположение единиц значения не имеет.

тут
1. Не Interbase, а Firebird
2. Там 100К строк а не 1М

Я не про IB/FB, а про DB2 фирмы IBM.
Задача ставилась про таблицу в 1000 колонок с 1 млн. строк.

А результат получен для 100K строк :
---------
Пробовал ваш пример на 1000 int колонках и 100 000 строк ( в мегабайтах):

COMPRESS
| Y | N
|---|----
COMPRESS SYSTEM DEFAULT |Y| 30 | 390
|N| 52| 781
------
...
Рейтинг: 0 / 0
31.07.2007, 20:34
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34696785
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
khl hvlad khlIBM DB2: при включенной компрессии указанная таблица (1000 х 1000000) занимает 30 Мб. Расположение единиц значения не имеет.

тут
1. Не Interbase, а Firebird
2. Там 100К строк а не 1М

Я не про IB/FB, а про DB2 фирмы IBM.
Задача ставилась про таблицу в 1000 колонок с 1 млн. строк.1. Где вы взяли данные Interbase ?
2. Внимательно перечитываем пост "Mark Barinstein" и пересчитываем нолики
...
Рейтинг: 0 / 0
31.07.2007, 20:35
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34696825
khl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
khl
Участник
hvlad khl hvlad khlIBM DB2: при включенной компрессии указанная таблица (1000 х 1000000) занимает 30 Мб. Расположение единиц значения не имеет.

тут
1. Не Interbase, а Firebird
2. Там 100К строк а не 1М

Я не про IB/FB, а про DB2 фирмы IBM.
Задача ставилась про таблицу в 1000 колонок с 1 млн. строк.1. Где вы взяли данные Interbase ?
2. Внимательно перечитываем пост "Mark Barinstein" и пересчитываем нолики
Про FB я взял данные на третьей странице этой темы.

Про нолики - в самом деле не хватает. Щас уточним, может он просто опечатался, т.к. я выше писал именно про 1М строк.
...
Рейтинг: 0 / 0
31.07.2007, 21:18
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34696838
khl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
khl
Участник
Да, судя по цифрам там для 100k строк.
Значит для 1М - 300 Мб.
...
Рейтинг: 0 / 0
31.07.2007, 21:28
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34696850
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
khlПро FB я взял данные на третьей странице этой темы.Вот и не нужно тогда ничего писать про Interbase
...
Рейтинг: 0 / 0
31.07.2007, 21:45
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34696861
###
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
###
Участник
Бред... Здесь дибил, конечно, я. Потому что:
SQL Server - 17.2 Гб
Oracle ??? - 1.11 Гб
Cache 5.2 - 17 Мб
Я не сторонник Cache, а, скорее, поклонник Oracle, но дибил просто потому что вот такие цифры получились.
Вранье... Сплошное вранье!!! Только что проверил: Cache 5.2 - 15 G !!!
...
Рейтинг: 0 / 0
31.07.2007, 21:57
| Ответить | Цитировать | Написать  
Разработка СУБД
    #34696893
khl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
khl
Участник
hvlad khlПро FB я взял данные на третьей странице этой темы.Вот и не нужно тогда ничего писать про Interbase
Ладно. Но ведь они вроде не сильно отличаются.
...
Рейтинг: 0 / 0
31.07.2007, 22:37
| Ответить | Цитировать | Написать  
195 сообщений из 195, показаны все 8 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Разработка СУБД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=35&tid=1553279]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 42ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 288ms
get tp. blocked users:
 1ms
others: 12ms
total:  388ms
созд. / загр.: 388ms
x
x
Закрыть


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