Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19   вперед  Ctrl
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
MX -- ALEX

думаю до статистики дело не дойдет ..

Я тоже склонен разделить этот скепсис. В постановке задачи видны признаки задач понимания естественного языка. Тада до БД еще далеко: там есь траблы с тем как вообще решать задачи и преодоление, которых в общем случае не очень известо. Это задачи ИИ - алгоритмов собсно хороших там не известно. Мож там не то шо БД, но и БЗ нарисуется, но не поможет. Смотря до какой степени качества нуно переводить.
Мож я не до конца понял, что хочет автор топика. Но пока такое впечатление присутствует.
8 май 06, 12:01    [2642774]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Iura
Member

Откуда:
Сообщений: 138
vadiminfo
MX -- ALEX

думаю до статистики дело не дойдет ..

Я тоже склонен разделить этот скепсис. В постановке задачи видны признаки задач понимания естественного языка. Тада до БД еще далеко: там есь траблы с тем как вообще решать задачи и преодоление, которых в общем случае не очень известо. Это задачи ИИ - алгоритмов собсно хороших там не известно. Мож там не то шо БД, но и БЗ нарисуется, но не поможет. Смотря до какой степени качества нуно переводить.
Мож я не до конца понял, что хочет автор топика. Но пока такое впечатление присутствует.


Процесс на стадии разработки. Есть концепция, но пока нет детального алгоритма.
Все решается поэтапно.
8 май 06, 13:24    [2642856]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
pavelvp
Member

Откуда:
Сообщений: 673
ну я
Именно. У версии, которая SU, кеш ограничен.
На фига же такая демо-версия...
8 май 06, 13:57    [2642898]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
pavelvp
ну я
Именно. У версии, которая SU, кеш ограничен.
На фига же такая демо-версия...

Вот такая вот у Интерсистемс бизнес-политика.
8 май 06, 14:49    [2642961]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
MX -- ALEX
Guest
ну я
pavelvp
ну я
Именно. У версии, которая SU, кеш ограничен.
На фига же такая демо-версия...

Вот такая вот у Интерсистемс бизнес-политика.


типа наш муму даже связаный и с камнем на шее
вашего тузика порвет..

горячие американские парни..
8 май 06, 15:10    [2642998]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
pavelvp
...
Записиси фиксированной длины никто уже давным-давно не хранит.
...

Ошибаешься, Павел.
IBM DB2 занимает примерно треть рынка БД. Из них 85% - это AS/400 DB2 (iSeries) , которая не умеет нормально работать с VARCHAR, да и традиционно используемый на этой платформе COBOL не силён в этой области. Как итог - поголовно используются записи фиксированной длины. Спасает только мощная дисковая система :[
8 май 06, 22:38    [2643725]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Anton Demidov

IBM DB2 занимает примерно треть рынка БД. Из них 85% - это AS/400 DB2 (iSeries) , которая не умеет нормально работать с VARCHAR, да и традиционно используемый на этой платформе COBOL не силён в этой области. Как итог - поголовно используются записи фиксированной длины. Спасает только мощная дисковая система :[


опа! вот это новость ... про кобол на as400 я слышал, но какое отношение он имеет к varchar? Информация точная?
9 май 06, 20:35    [2644841]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ggv
Member

Откуда:
Сообщений: 1810
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/db2/rbafzmstch2data.htm
10 май 06, 12:23    [2646891]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp
Итак. Имеем следующее:
- Cache 5.1.0.826.1.SU;
- ЛИНТЕР 6.1.6.12.
Создаём таблицу. Реальная табла, из реальной системы. В таблице 59 полей, из которых 50 - varchar(40). Заливаем миллион записей в которых все последние 50 полей NULL-значения. Скорость загрузки комментировать не буду (т.к. SQL-ем в Cache грузил, а не COS), да я и не засекал.
Что получилось:
Cache - 234М
ЛИНТЕР - 220М :-)))
Разница по сравнению с ЛИНТЕР в 14М видимо тот самый индекс по ID :-)
Вопрос - что я делал не так?

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

ну да ладно. пара пояснений. реализация "реляционного" подхода в
Cache аналогична по идеологии с РСУБД. это значит, что будут эмулироваться
фиксированные размеры полей. это значит, что будут имитироваться
"плоские" таблицы. это значит, что все будет медленнее, чем хотелось
и толще, чем моглось... только не надо ловить меня на словах, ладно? я обещал "быстрый и компактный SQL на простых запросах", ага,
но я с ним не работаю (да и не буду).
наверно тебе могут что-то подсказать другие здешние M-щики.
свой подход я объяснил на пальцах и по мере возможности
показал. я могу оценить примерную загруженность нормального M-массива,
если ты все-таки расскажешь про размер оставшихся 9-ти полей. :)


Ещё пара слов про 210М в ЛИНТЕР. У нас есть параметр у таблицы PCTFILL - процент сжатия данных. Этот параметр подсказывает субд насколько, в среднем исходные данные могут быть сжаты. По-умолчанию, при создании таблицы, этот параметр считается равным 100. Если его поставить, например, равным 30, то 220М превратятся уже 117М :-) Т.е. в два раза меньше, чем у Каше :-) У MS SQL, кстати, эта таблица будет занимать тоже уколо сотни метров... У ЛИНТЕР чуть больше из-за секьюрити - на каждую строку несколько байт с метками доступа хранится.

должен ли я полагать, что 100 - означает 100% сжатия данных? :)
как-то слабо верится, ага. причем сжатие данных - вещь, конечно
реальная до определенной степени, пока не начинает сурово влиять
на скорость обработки.


Ну и ещё пара экспериментов в догонку. По скорости. Тут говорили, что даже SQL в Каше офигенный просто, а уж напрямую так вообще улёт.
Вот такие нехитрые вещи я попробовал:
1) count(*)
2) max
3) min
4) avg
5) sum
6) between 10000 and 100000
7) order by
По полю типа double.
Как видно, никакой "реляционщиной" здесь и не пахнет (может быть за исключением последнего :-)). Вроде как Каше должен на них просто летать. Индексов, естественно, никаких не строилось.

тут, видимо, я должен извиниться? нет уж, не буду. пусть тебе ответят те,
кто занимается SQL в Cache, это не моя специфика.


В чём правда, брат?

в честных сравнениях, брат.


Что я делал не так? База получилась больше... Скорость ниже... Может нужно таблицу побольше взять, миллионов на 100 или 500... и тогда мы увидим фантастическую экономию дискового пространства и невероятную скорость работы...

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


Так что чудес не бывает :-) Если данные есть - они занимают место :-)
Записиси фиксированной длины никто уже давным-давно не хранит.
Префиксное сжатие ключей в индексах думаю тоже у всех есть.
При схожих объёмах - размер БД у всех будет примерно одинаковый (если нет компрессии данных).

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


Если нет индексов - фуллскан - скорость диска от СУБД не зависит :-)

скорость диска - конечно же не зависит. но на одном и том же винте
разные СУБД будут обрабатываться по-разному


Всё зависит от оптимизатора, короче говоря :-))) И вот ради этой последней строчки столько фигни написал :-)

ну почему же сразу "фигни"? твое право. просто возможности оптимизации
РСУБД заканчиваются, если уже не закончились.

С уважением. Сергей
10 май 06, 12:31    [2646947]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ggv
Member

Откуда:
Сообщений: 1810
ну и как всегда вызывают сомнения цифири распределения баз по типам.
Anton - есть ссылочка, или это ваше IMHO?
которое почему-то не указано...
10 май 06, 12:39    [2646997]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Anton Demidov
pavelvp
...
Записиси фиксированной длины никто уже давным-давно не хранит.
...

Ошибаешься, Павел.
IBM DB2 занимает примерно треть рынка БД. Из них 85% - это AS/400 DB2 (iSeries) , которая не умеет нормально работать с VARCHAR, да и традиционно используемый на этой платформе COBOL не силён в этой области. Как итог - поголовно используются записи фиксированной длины. Спасает только мощная дисковая система :[


да, а как же приведенная ggv ссылка относительно кобола и varchar?

VARCHAR varying-length character-string variables can be used in C, COBOL, PL/I, REXX, and RPG:

...
* In COBOL and C, varying-length character strings are represented as structures.
...
10 май 06, 13:26    [2647392]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
нда... подход. а ведь я говорил же, что SQL в Cache боковой, на коленке сделанный, в псевдо-компилятор засунутый... что же ты сравниваешь-то?
Сравниваю подсистему хранения данных. Какое оно имеет отношение к SQL не понимаю...

ну да ладно. пара пояснений. реализация "реляционного" подхода в
Cache аналогична по идеологии с РСУБД. это значит, что будут эмулироваться
фиксированные размеры полей.
Зачем??? И какой идеологии? Пока мы выяснили, что фиксированные размеры полей у DBF (причём здесь РСУБД?) и у одной из версий DB2.
это значит, что будут имитироваться
"плоские" таблицы. это значит, что все будет медленнее, чем хотелось
и толще, чем моглось...
Т.е. по каким-то непонятным причинам Каше специально делает чтобы работало медленно???
только не надо ловить меня на словах, ладно?
Никого я не собирался ловить на словах. Только и тебя за язык никто не тянул.

я могу оценить примерную загруженность нормального M-массива,
если ты все-таки расскажешь про размер оставшихся 9-ти полей. :)

Да не смеши ты людей :-) Знаю я сколько он будет занимать - чуть больше 100 метров, никуда ты данные не выкинешь...
Если тебе не сложно - расскажи как мне создать глобал и загрузить данные "честно". Попробую.

есть параметр у таблицы PCTFILL - процент сжатия данных.

должен ли я полагать, что 100 - означает 100% сжатия данных? :)
как-то слабо верится, ага.
PCTFILL - процент заполнения. 100 - данные не сжимаются.
Ну и ещё пара экспериментов в догонку. По скорости.

тут, видимо, я должен извиниться? нет уж, не буду. пусть тебе ответят те,
кто занимается SQL в Cache, это не моя специфика.

Ну да, я уже понял. Типа специально тормоза сделали. Видимо для демонстрации превосходства :-\ Только уж если у программеров самого Каше такие проблемы есть, то возникают некоторые сомнения...


В чём правда, брат?

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

Вот два утверждения двух разных людей:
Sergei Obrastsov
Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом.
Iura
Как показывают тесты, производительность Cache SQL как минимум в три раза выше,
чем у традиционных реляционных СУБД, использующих реляционное ядро.


В моём тесте оба этих утверждения оказались неверными. При этом я не понимаю какое отношение SQL имеет к хранению данных, операции count(*), и вычислению простейщих агрегатов. Я же не джойны хитрые с группировками делал... Однако, если по первому пункту ты хоть как-то "прояснил" ситуацию, то то, что поведал Iura, отказалось просто неправдой.


занимают. только разное
я заметил :-)
не хранят. но хранят описание
ты о чём???


скорость диска - конечно же не зависит. но на одном и том же винте
разные СУБД будут обрабатываться по-разному
и ты говоришь мне, чтобы я к словам не придирался, а сам что же :-)

просто возможности оптимизации
РСУБД заканчиваются, если уже не закончились.
Ну да, конечно :-) А у М эти возможности воистину безграничны... Кстати, может подскажешь - есть ли в M возможность при программировании учесть объём данных конкретного глобала удерживаемый в данный момент в буферном пуле?

Ни в коей мере я не пытался сравнивать M-технологию и РСУБД. Но только коли речь идёт об РСУБД, то будь добр - ориентируйся на современных представителей этого семейства - всё-таки 21-ый век на дворе.
10 май 06, 13:52    [2647555]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
pavelvp
Т.е. по каким-то непонятным причинам Каше специально делает чтобы работало медленно???

Движок sql руководствуясь только sql не может определить как ЛУЧШЕ хранить данные, поэтому использует стратегии хранения по умолчанию. Эта стратегия примерно соответствует таблицам с кластерным первичным ключом. Тупо и в лоб.

Sergei Obrastsov
Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом.

У кластерного ключа сжатию взяться неоткуда, если в нем только одно поле. Чтобы было сжатие, нужно несколько полей в ключ.

Iura
Как показывают тесты, производительность Cache SQL как минимум в три раза выше,
чем у традиционных реляционных СУБД, использующих реляционное ядро.


Расскажите это фокспрошникам. Что и когда быстрее - зависит от столь большого числа факторов, что провести корректные стендовые испытания довольно сложно.
pavelp
есть ли в M возможность при программировании учесть объём данных конкретного глобала удерживаемый в данный момент в буферном пуле?

По стандарту М - нет. Среди документированных возможностей каше что-то не встречал. Инфа может быть в каких-то внутренних структурах системы сбора статистики, какая-нибудь хитроумная недокументированная системная функция. Интерсистемс иногда делает спецбилды со спецвозможностями для отдельных клиентов. Если сильно нужно - могут пойти навстречу. Поэтому не могу достоверно отрицать что такой возможности совсем нет.
10 май 06, 14:15    [2647711]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
ну я
pavelp
есть ли в M возможность при программировании учесть объём данных конкретного глобала удерживаемый в данный момент в буферном пуле?

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

Справедливости ради должен упомянуть о системе сбора статистики ^GLOSTAT и интерфейсе к сбору статистики через классовые интерфейсы, в частности классы пакета $System.MONITOR. Но как из операционных статистик выудить итоговые - таким вопросом пока не задавался.
10 май 06, 14:34    [2647843]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp
Sergei Obrastsov
нда... подход. а ведь я говорил же, что SQL в Cache боковой, на коленке сделанный, в псевдо-компилятор засунутый... что же ты сравниваешь-то?
Сравниваю подсистему хранения данных. Какое оно имеет отношение к SQL не понимаю...
не понимаешь, ага. ты берешь "эмулированную подсистему хранения данных для эмулированного SQL" и хочешь назвать это оптимальной системой.
не правильно, мягко говоря

pavelvp
Sergei Obrastsov
ну да ладно. пара пояснений. реализация "реляционного" подхода в Cache аналогична по идеологии с РСУБД. это значит, что будут эмулироваться фиксированные размеры полей.
Зачем??? И какой идеологии? Пока мы выяснили, что фиксированные размеры полей у DBF (причём здесь РСУБД?) и у одной из версий DB2.

а у тебя в РСУБД не так? или ты полагаешь, что VARCHAR(x) не есть указание
на предельный размер поля? не надо быть наивным

pavelvp
Sergei Obrastsov
это значит, что будут имитироваться
"плоские" таблицы. это значит, что все будет медленнее, чем хотелось
и толще, чем моглось...
Т.е. по каким-то непонятным причинам Каше специально делает чтобы работало медленно???

по вполне понятным причинам Cache тащит за собой эмулированный SQL,
подгоняя под него вполне определенного вида структуры. это не есть
язык системы, это не есть оптимальные структуры хранения данных

pavelvp
Sergei Obrastsov
только не надо ловить меня на словах, ладно?
Никого я не собирался ловить на словах. Только и тебя за язык никто не тянул.

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

pavelvp
Sergei Obrastsov
я могу оценить примерную загруженность нормального M-массива, если ты все-таки расскажешь про размер оставшихся 9-ти полей. :)
Да не смеши ты людей :-) Знаю я сколько он будет занимать - чуть больше 100 метров, никуда ты данные не выкинешь...
Если тебе не сложно - расскажи как мне создать глобал и загрузить данные "честно". Попробую.

совершенно не сложно. только я не зря спрашиваю про строку.
что она из себя представляет? если разделитель - то какой? если
по позициям, то каковы они? ну предположим, что строка следующего вида:
data1 data2 data3 ... data59
(59 полей разделены пробелами, в случае NULL так и пишется NULL)
то есть:
data1 NULL NULL data4 ... data59
k ^tmp
s file="x:\...\xxx.xxx" ;файл и путь к нему
o file u file
s idx=0 ;а это индекс
f  r str q:$zeof<0  d  ;читаем в цикле строку из файла
. s str=$tr(str," ","*") ;меняем пробелы в строке на *, а можно и на что другое
. s str=$tr(str,"NULL","") ;заменяем NULL на <пусто>
. s str=$zstrip(str,"*",">") ;обрезаем строку до последнего значимого поля
. s idx=idx+1
. s ^tmp(idx)=str
c file
(скорее всего вылетит на ошибку в конце файла, потому что не выставлено
использование $ZEOF в этом случае, меняется в конфигурации. но это уже
не играет роли, все-равно уже прочитал)
понятно, что здесь еще можно поизгаляться с оптимизацией самого кода,
но это уже мелочи, ага.
программу создаешь в Studio, запускаешь в терминале. желательно это
сделать в только что созданной базе данных.

pavelvp
Ну да, я уже понял. Типа специально тормоза сделали. Видимо для демонстрации превосходства :-\ Только уж если у программеров самого Каше такие проблемы есть, то возникают некоторые сомнения...

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

pavelvp
Вот два утверждения двух разных людей:
Sergei Obrastsov
Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом.
Iura
Как показывают тесты, производительность Cache SQL как минимум в три раза выше,
чем у традиционных реляционных СУБД, использующих реляционное ядро.


В моём тесте оба этих утверждения оказались неверными. При этом я не понимаю какое отношение SQL имеет к хранению данных, операции count(*), и вычислению простейщих агрегатов. Я же не джойны хитрые с группировками делал... Однако, если по первому пункту ты хоть как-то "прояснил" ситуацию, то то, что поведал Iura, отказалось просто неправдой.

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

pavelvp
Sergei Obrastsov

занимают. только разное
я заметил :-)
не хранят. но хранят описание
ты о чём???

о реляционных структурах.
где фиксированные по длине строки и описания полей

pavelvp
Sergei Obrastsov
скорость диска - конечно же не зависит. но на одном и том же винте разные СУБД будут обрабатываться по-разному
и ты говоришь мне, чтобы я к словам не придирался, а сам что же :-)

чтобы ты отыгрался :)

pavelvp
Sergei Obrastsov
просто возможности оптимизации
РСУБД заканчиваются, если уже не закончились.
Ну да, конечно :-) А у М эти возможности воистину безграничны... Кстати, может подскажешь - есть ли в M возможность при программировании учесть объём данных конкретного глобала удерживаемый в данный момент в буферном пуле?

нет ничего безграничного. но возможности M достаточно широки.
что конкретно тебя интересует? сколько именно блоков конкретного массива
там находится? можно. а зачем?

pavelvp
Ни в коей мере я не пытался сравнивать M-технологию и РСУБД. Но только коли речь идёт об РСУБД, то будь добр - ориентируйся на современных представителей этого семейства - всё-таки 21-ый век на дворе.

и поэтому "а сбацай-ка нам SQL запрос"? :)
я еще раз проясню свою позицию: я НЕ против РСУБД, я уважаю людей, которые их развивают и которые в них работают. я НЕ ратую за отмену
всех РСУБД и замену их M-системами. я всего лишь против оплевывания
системы, которая наконец-то начала пробиваться на этот рынок.

С уважением. Сергей
10 май 06, 15:00    [2648068]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Sergei Obrastsov
Фактически, Cache хранит эти же данные МИНИМУМ в 2 раза меньшим
объемом.

У кластерного ключа сжатию взяться неоткуда, если в нем только одно поле. Чтобы было сжатие, нужно несколько полей в ключ.

стоп-стоп. во-первых, что есть "кластерный ключ"? для тупых, уж извини.
во-вторых, сжатие работает по ссылке. то есть:

^xxx(10000)
^xxx(10001)

даст нам остаток ссылки в "1". данные конечно не жмутся, если их не жать
собственноручно. :)
но! а нафига я буду писать данные в такую тривиальную структуру?
я совмещу ее с нужным индексом сразу, ага. в РСУБД такого нет. там
индекс навешивается отдельно, а будучи навешен, увеличивает размеры БД...кхгм... сильно.

С уважением. Сергей
10 май 06, 15:09    [2648129]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Sergei Obrastsov
во-первых, что есть "кластерный ключ"? для тупых, уж извини.
во-вторых, сжатие работает по ссылке. то есть:

^xxx(10000)
^xxx(10001)

даст нам остаток ссылки в "1". данные конечно не жмутся, если их не жать
собственноручно. :)
но! а нафига я буду писать данные в такую тривиальную структуру?
я совмещу ее с нужным индексом сразу, ага. в РСУБД такого нет. там
индекс навешивается отдельно, а будучи навешен, увеличивает размеры БД...кхгм... сильно.

С уважением. Сергей

А тупых программистов не бывает. (С) полковник Борисов.

В схеме хранения ^gloname(id)=values если мы считаем id частью строки, то это ключ кластерного индекса. Если не считаем, то это автоматически заведенный некими соглашениями для целей хранения, вроде ораклового rowid.

Если посчитаем ключом не одно поле а сочетание нескольких, например
^gloname(field1,field2)=othervalues
То тут и может проявитсья сжатие ключей.

Ну, а как писать или не писать - это не технический вопрос, к сжатию отношения не имеет.
10 май 06, 15:26    [2648259]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
ну я
А тупых программистов не бывает. (С) полковник Борисов.

как видишь, все же есть. :)

ну я

В схеме хранения ^gloname(id)=values если мы считаем id частью строки, то это ключ кластерного индекса. Если не считаем, то это автоматически заведенный некими соглашениями для целей хранения, вроде ораклового rowid.

угу, теперь ясно, спасибо. вот ведь, любят люди красивые слова. :)

ну я

Если посчитаем ключом не одно поле а сочетание нескольких, например
^gloname(field1,field2)=othervalues
То тут и может проявитсья сжатие ключей.

снова не понял. ты хочешь сказать "сжатие данных" за счет помещения части
из них в автоматически жмущиеся индексы?

С уважением. Сергей
10 май 06, 15:45    [2648377]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Sergei Obrastsov
ну я

Если посчитаем ключом не одно поле а сочетание нескольких, например
^gloname(field1,field2)=othervalues
То тут и может проявитсья сжатие ключей.

снова не понял. ты хочешь сказать "сжатие данных" за счет помещения части
из них в автоматически жмущиеся индексы?

С уважением. Сергей

У меня нет полной уверенности что в случае
^gloname(100)
и
^gloname(101)
хранится лишь разница в 1. Я могу не знать таких деталей. Но в случае
^gloname(123,456)
и
^gloname(123,789)
величина 123 скорее всего будет храниться только 1 раз на блок. Вот про этот случай я и писал.
10 май 06, 15:53    [2648443]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Sergei Obrastsov
. s str=$zstrip(str,"*",">") ;обрезаем строку до последнего значимого поля

черт, ошибся. вот так:
. s str=$zstrip(str,">P")
извини

С уважением. Сергей
10 май 06, 15:54    [2648452]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov

совершенно не сложно. только я не зря спрашиваю про строку.
что она из себя представляет? если разделитель - то какой? если
по позициям, то каковы они? ну предположим, что строка следующего вида:
data1 data2 data3 ... data59
(59 полей разделены пробелами, в случае NULL так и пишется NULL)
то есть:
data1 NULL NULL data4 ... data59

Строка следующего вида:
,data1,data2,<NULL> ... data59,

k ^tmp
s file="x:\...\xxx.xxx" ;файл и путь к нему
o file u file
s idx=0 ;а это индекс
f  r str q:$zeof<0  d  ;читаем в цикле строку из файла
. s str=$tr(str," ","*") ;меняем пробелы в строке на *, а можно и на что другое
. s str=$tr(str,"NULL","") ;заменяем NULL на <пусто>
. s str=$zstrip(str,"*",">") ;обрезаем строку до последнего значимого поля
. s idx=idx+1
. s ^tmp(idx)=str
c file

Возникли вопросы:
- зачем пробелы замеяются на другие символы?
- почему в индекс пихается вся строка в сыром виде?
- где собственно мои 59 полей?
- типы данных (timestamp, double и т.п.) мне потом самому интерпретировать?

Ну и собственно как мне эту программу запустить? :-)
Студия предлагает создать прграмму на COS, Cache Basic и т.п. Ни в одном из вариантов не компилится. Непонятно...
И как её потом запустить...
10 май 06, 15:57    [2648475]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
ну я
У меня нет полной уверенности что в случае
^gloname(100)
и
^gloname(101)
хранится лишь разница в 1. Я могу не знать таких деталей.

фактически - да, с учетом двух цифирь (длина совпадающей части, длина несовпадающей части). если хочешь, давай расковыряем блок и посмотрим :)

ну я

Но в случае
^gloname(123,456)
и
^gloname(123,789)
величина 123 скорее всего будет храниться только 1 раз на блок. Вот про этот случай я и писал.

да, так и есть. это вытекает как раз из принципа сжатия ссылки.

С уважением. Сергей
10 май 06, 16:01    [2648498]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
pavelvp
Member

Откуда:
Сообщений: 673
ну я
А тупых программистов не бывает. (С) полковник Борисов.

Колись, "ну я", ты кто такой? :-) Безобразие - ты меня знаешь, я тебя нет :-)
Но в случае
^gloname(123,456)
и
^gloname(123,789)
величина 123 скорее всего будет храниться только 1 раз на блок. Вот про этот случай я и писал.
Создаётся впечатление, как будто только Каше так поступает :-)))
10 май 06, 16:02    [2648506]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pavelvp

Строка следующего вида:
,data1,data2,<NULL> ... data59,
[/quot ]
славно, можно не мудрить с другими разделителями

[quot pavelvp]
Возникли вопросы:
- зачем пробелы замеяются на другие символы?

привычка. можно и не менять. логически пробел не свойственен в качестве
разделителя. а вдруг в поле будет ФИО?

pavelvp

- почему в индекс пихается вся строка в сыром виде?

стоп-стоп. в данное, а не в индекс, ага

pavelvp

- где собственно мои 59 полей?

в данном, конечно :) вот эта вся твоя строка и есть строка данных, с разделителем ","

pavelvp

- типы данных (timestamp, double и т.п.) мне потом самому интерпретировать?

а зачем? здесь нет типов данных

pavelvp

Ну и собственно как мне эту программу запустить? :-)
Студия предлагает создать прграмму на COS, Cache Basic и т.п. Ни в одном из вариантов не компилится. Непонятно...
И как её потом запустить...

на COS. просто переносишь ее туда. обрати внимание, что перед каждой
строкой надо поставить <Tab>, иначе первый символ воспримется как метка.
при сохрание "Save as..." выбери Files of type -> Intermediate Routine (*.int),
имя хоть бы и tmp.
запускаешь терминал, d ^tmp

С уважением. Сергей
10 май 06, 16:21    [2648624]     Ответить | Цитировать Сообщить модератору
 Re: Новое сравнение (SQL 2005, Oracle 10G, Cache 5, MySQL - cat2 :) )  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Sergei Obrastsov
о реляционных структурах.
где фиксированные по длине строки и описания полей

Маленький комментарий. Реляционная модель чисто логическая и не имеет отношения к физическим структурам и принципам хранения. Хорошо бы вам сразу на берегу это признать. И конкретные структуры хранения являются особенностями реализации конкретной РСУБД. И таковых множество. Хранение по строкам, да еще и с фиксированном их размером есть только один из подходов. Есть хранение по столбцам (см. Sybase IQ), есть IOT (Oracle), есть модель TransRelational. Да и "по строкам" хранять можно по разному.

Не ясно, почему вы с таким упорством говорите о "реляционных структурах" физического хранения, ведь такого понятия просто не существует.
10 май 06, 16:23    [2648641]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 10 11 12 13 14 [15] 16 17 18 19   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить