Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 35 36 37 38 39 [40] 41 42 43 44 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

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

1. Поскольку я работаю в одиночку, вопрос с контролем версий у меня не стоит. Знакомая фирма
использует CSV, вроде. Правда, примитивный контроль версий Cache ведет на уровне программ, но
это мелочь конечно.
2. Даже не знаю, что и сказать, никогда не задумывался. Слишком общий вопрос. Что конкретно интересует по отладке?
3. Backup развит достаточно хорошо. На физическом уровне (блоки БД) - полный и инкрементный.
Копирование глобалей ссылками/данными и блоками. Ну и плюс журналирование глобалей.
18 ноя 06, 12:49    [3419069]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
А вы не читали ту ссылку? (http://thedailywtf.com/forums/post/60692.aspx) Автор утверждает, что
Sergei Obrastsov

1. Поскольку я работаю в одиночку, вопрос с контролем версий у меня не стоит. Знакомая фирма
использует CSV, вроде. Правда, примитивный контроль версий Cache ведет на уровне программ, но
это мелочь конечно.

архитектура хранения кода не позволяет пользоваться системами контроля версий.
Sergei Obrastsov

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

Сообщения об ошибках затрудняют поиск места, в котором эта ошибка случилась. Раз уж код интерпретируемый, это действительно недосток, обычно они таки ссылаются на реальные строки кода.
Sergei Obrastsov

3. Backup развит достаточно хорошо. На физическом уровне (блоки БД) - полный и инкрементный.
Копирование глобалей ссылками/данными и блоками. Ну и плюс журналирование глобалей.

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

Безусловно, неизвестно кто с неизвестно какого сайта не является безоговорочным авторитетом, но поводом выяснить эти вопросы -- пожалуй, да.) Итак, всё вышесказанное, в реальности места не имеет?
18 ноя 06, 13:02    [3419086]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

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

[quot DocAl]А вы не читали ту ссылку? (http://thedailywtf.com/forums/post/60692.aspx)

Читал. Даже ответил, но письмо улетело в новую тему почему-то. Не стал повторять.

DocAl

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

Существует глобаль ^rBACKUP где хранятся все старые версии программ. Не проверял правда
глубину хранения, в смысле через какое число копий начинается ротация.
Global ^rBACKUP
^rBACKUP("x","INT",1)=2006-11-11 11:49:50®
^rBACKUP("x","INT",1,0)=60580,42590
^rBACKUP("x","INT",1,0,0)=3
                       1)=x             ;  ; Compiled November 11, 2006 11:49:05
                       2)=1             s c=0,t=$zh
                       3)=              w !,c,"  ",$zh-t
                  "SIZE")=174
^rBACKUP("x","INT",1,"LANG")=
^rBACKUP("x","INT",2)=2006-11-18 21:09:19
^rBACKUP("x","INT",2,0)=60587,76159
^rBACKUP("x","INT",2,0,0)=4
                       1)=x             ;
                       2)=1             ;
                       3)=              q  ;1
                       4)=
                  "SIZE")=21
^rBACKUP("x","INT",2,"LANG")=
^rBACKUP("x","INT",3)=2006-11-18 21:09:54$
^rBACKUP("x","INT",3,0)=60587,76194
^rBACKUP("x","INT",3,0,0)=7
                       1)=x             ;
                       2)=1             ;
                       3)=              q  ;1
                       4)=
                       5)=2             ;
                       6)=              q  ;2
                       7)=
                  "SIZE")=36
^rBACKUP("x","INT",3,"LANG")=

DocAl

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

Только в том случае, если исходник удален. Есть такая возможность в системе - оставить только п-код. Обычно это делается на коммерческих продуктах. Если же исходник в наличии, то:
USER>d ^x
 
  s a=0,b=1 w c
            ^
<UNDEFINED>1+1^x
USER 2d0>

DocAl

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

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

DocAl

Безусловно, неизвестно кто с неизвестно какого сайта не является безоговорочным авторитетом, но поводом выяснить эти вопросы -- пожалуй, да.) Итак, всё вышесказанное, в реальности места не имеет?

Я ответил, Вам решать. :)
18 ноя 06, 13:23    [3419106]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Sergei Obrastsov
1. Поскольку я работаю в одиночку, вопрос с контролем версий у меня не стоит.

Хм.... В сторону, конечно, но любопытно.
18 ноя 06, 13:31    [3419114]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Croaton
"Физиология" внутреннего хранения: http://drus.boom.ru/StoreCache.pdf
Ну нет тут индексов в понимании РСУБД. Так-же как скачков к данным по логарифму. Так как соседние блоки в курсе друг о друге....


ГЫ-ГЫ-ГЫ!!!!!!! Не, ну это просто цирк, господа! Ещё один клоун :-)))
Ох я и поржал, аж до слёз... :-)))
Замечательный документик господа. Рекомендую всем посмотреть.
Особенно рекомендую этот документик 2 Sergei Obrastsov.
Sergei Obrastsov, обратите внимание на следующие строки:
StoreCache.pdf
Ядро СУБД Caché использует B+-деревья для хранения данных...
После имени глобала в круглых скобках через запятую
указывается произвольное количество индексов. Компилятор осуществляет
преобразование всего множества индексов в ключ B+-дерева...


Это то, что Вам тут пытаются объяснить несколько человек уже несколько дней.

Croaton
Продолжение про "физиологию"
При форсмажорных разрушениях диска, эта байда(дерево) прикольно восстанавливается(хоть и давненько, но попадал).
"Сбрасывается" информация о дереве(верхний блок указателей).
Остальные блоки несут(В СЕБЕ!) информацию о родителе и братьях.(Если Вы Иван Сергеевич, то имя отца очевидно(хотя не факт=) ). Кто-нибудь свою генеалогию собирал? - то-же самое.
50% метаний горшков на форуме, из-за непонимания внутреннего строения M.
А уж каша там название, или малаша это не главное.
Красиво написанный логарифмические перемещения - частный случай M.

А Sergei Obrastsov молодца держится, только зря...

M 10 лет,Oracle DBA, 4 года.


Точно! Из-за непонимания этого господином Sergei Obrastsov! И некоторыми другими, за исключением ну я.
Тут необходимо прокомментировать перлы про "как скачков к данным по логарифму" и "логарифмические перемещения".
Комментарий для ламеров. Цитата из документика (прочитав который начинаешь сомневаться в компетентности автора :-)):
StoreCache.pdf
В блоках предусмотрены дополнительные ссылки предназначенные
для контроля за целостностью B+-дерева. Такие ссылки расположенные в листьях дерева
обеспечивают последовательный доступ ко всему содержимому глобала.

Эти ссылки нужны не для контроля целостности дерева! Они нужны только, и только для того, чтобы обеспечить быстрое выполение сканирования дерева, и ни для чего больше!
В этом и фишка B+-tree:
- узлы не содержат данных;
- все данные в листья;
- листья связаны ссылками.
А есть ещё алгоритмически улучшенное дерево, которое называется В*-дерево.
В нём улучшен алгоритм встаки, что позволяет: уменьшить использование дискового простанства, увеличить скорость добавления данных (из-за уменьшения количества делений узлов), увеличить скорость поиска (уровень дерева меньше).

Комментарий для профессионалов (ламерам почитать тоже рекомендуется).
Ребята, тут многое проясняется :-) Хотя может автор статейки и гонит про B+-tree, может но такой же ламер, может там всё-таки B*-... Но обратите внимание! Не B*- используется, а B+-tree.
Не используется алгоритм переливания. Соответственно:
1) дерево чаще делится, т.е. имеет большее кол-во уровней;
2) занимает больше места на диске :-)
Что и было подтверждено недавно в этом же топике :-) Да я и сам пробовал (сравнивал с ЛИНТЕР, Oracle, Sybase). Во всех случаях БД этих СУБД (таблица+индекс) получалась меньше на 10-30%, т.к. все эти СУБД используют B*-деревья.
Мне даже пришло в голову объяснение почему в М используется B+. Чисто по историческим соображениям :-) MUMPS появился в 1967 году. Непонятно, что тогда использовалось для хранения, но видимо нечто подобное, т.к. B- и B+- tree были детально проработаны только 1972 году, а B*- позже. Вот видимо с тех пор у них ничего и не менялось :-)))
И до меня только сейчас дошло, что Sergei Obrastsov (а теперь и Croaton) думают что РСУБД с каждым ключом каждый раз ползают по веткам деревяхи :-)))
18 ноя 06, 13:43    [3419128]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iscrafm
Member [заблокирован]

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

И до меня только сейчас дошло, что Sergei Obrastsov (а теперь и Croaton) думают что РСУБД с каждым ключом каждый раз ползают по веткам деревяхи :-)))


[quot pavelvp] Из-за непонимания этого господином Sergei Obrastsov! И некоторыми другими, за исключением ну я.

так кроме тебя же все ламеры, что жы ты хотел.
18 ноя 06, 13:51    [3419138]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
Уф... Еще раз, надеюсь последний.
Предпосылка: утверждение, что таблица с двумя полями адекватна дереву.
Дано: дерево. рабочее, с развешанными внутри перекрестными ссылками для повышения производительности.

Пипец... :-))) А эти перекрёстные, как Вы говорите, ссылки в поле таблицы не влазят что-ли? :-)))
Ещё раз. Вот Ваш пример:
Sergei Obrastsov

Поясняю. Скажем, индексы выглядят следующим образом:
^dft(59901,25081565,34744,"qxQ")=
^dft(59901,25081565,79658,"5Me")=
^dft(59901,25081565,9148513041,"pQ")=
^dft(59901,25081567,76909,"qyZ")=
^dft(59901,25081567,9148502606,283)=
^dft(59901,25081567,9148502606,"x5f")=
^dft(59901,25081570,73798,"lTr")=
^dft(59901,25081571,53189,"bFt")=
^dft(59901,25081571,75270,"c1I")=
^dft(59901,25081571,75270,"c1W")=
^dft(59901,25081571,75270,"c6Q")=
^dft(59901,25081575,9148502606,"qf")=
Итак, задание - при заданных 1-м и 2-м уровне, выбрать соответствующий 3-й.
Решение банально:
59901 -> 25081567 -> 76909
                     9148502606
                     9148502606
Ну а теперь, выберем все соответствующие записи для заданного 3-го, при отсутствии
2-го и 1-го. Скажем задан "9148502606". Каким интересно образом это можно сделать без
Full Scan?


Как в Вашей структуре мне попасть

^dft(59901,25081565,34744,"qxQ")=
^dft(59901,25081565,79658,"5Me")=
^dft(59901,25081565,9148513041,"pQ")=
^dft(59901,25081567,76909,"qyZ")=
                    ^ вот сюда
если не известны первые два индекса?
как выбрать всё, что больше 76909?
как выбрать всё, что между 53189 и 76909?

^dft(59901,25081567,9148502606,283)=
^dft(59901,25081567,9148502606,"x5f")=
^dft(59901,25081570,73798,"lTr")=
^dft(59901,25081571,53189,"bFt")=
^dft(59901,25081571,75270,"c1I")=
^dft(59901,25081571,75270,"c1W")=
^dft(59901,25081571,75270,"c6Q")=
^dft(59901,25081575,9148502606,"qf")=

Пальцем покажите, пожалуйста. Вот на этом конкретном примере.
18 ноя 06, 13:59    [3419150]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
iscrafm
[quot pavelvp] Из-за непонимания этого господином Sergei Obrastsov! И некоторыми другими, за исключением ну я.

так кроме тебя же все ламеры, что жы ты хотел.

Не понял твоего ответа. Наверное ты про "ну я" ?
Это не про меня :-) Это ник такой у человека ну я.
18 ноя 06, 14:03    [3419160]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
pavelvp
Это ник такой у человека ну я.

:)
18 ноя 06, 14:05    [3419162]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Sergei Obrastsov
>>Ой-ей. Да откуда ж такая дискретность-то?!

У каждого свои заморочки не так ли. %) Если поднапрячся можно и сократить конечно штук ~ 50 НО ЗАЧЕМ?!
Что бы дать возможность разрабам ошибаться в написании "имени секции" и увлекательнейшей задачки кто быстрее найдет потом "кривой запрос"?

>>Можете намекнуть на принадлежность проекта?
Помесь всего понемного. Автоматизация+биллинг+работа с клиентами

DocAl
>>как решаются вопросы с контролем версий, отладкой, бакапами?

Подключением внешней VS системы через встроенный "шлюз". Есть для VSS и CVS.
Сам доставал версию с CVS с целью переписать на SVN.

Отладка имеется. Я даже видел людей которые ей пользуються :) Мне пока увы не пригодилось.

Бэкап ? Встроенный - а что ?
18 ноя 06, 16:06    [3419322]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
DocAl
>>архитектура хранения кода не позволяет пользоваться системами контроля версий.

Да.... ???? От блин.
Если автор не осилил выгрузку внутренний описаний и прозрачный для современных систем контроль внешних .csp файлов - то это вопрос к компетенции автора я думаю.

>>Сообщения об ошибках затрудняют поиск места, в котором эта ошибка случилась.

В "системных" сообщениях указано место возникновения ошибки. Программа + номер строки.
Не говоря уже о том что такое "трап ошибка" вообще то полный форс-мажор.

Если же разработчик устанавливает свои обработчики ошибок - и пишет в описании "Ошибка блин" :) то как говориться ССЗБ.

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

Свое мнение по источнику я уже выразил - системная область - точно такая СУБД.
С точно такими же глобалами - Бэкапте её как вам заблогаруссудится - хоть эталонную в архив кладите.
18 ноя 06, 16:20    [3419352]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
pavelvp

>>Пальцем покажите, пожалуйста. Вот на этом конкретном примере.

set x="^dft"
for  { set x=$q(@x) quit:x=""  quit:$qs(x,3)=76909 } 
write:x="" @x

set x="^dft"
for  { set x=$q(@x) quit:x=""  quit:$qs(x,3)>=53189 } 
if x'="" { set x(1)=$qs(x,1),x(2)=$qs(x,2),x=$qs(x,3)-1
	for  { set x=$o(^dft(x(1),x(2),x),1,x(3)) quit:x=""  quit:x>76909 
		w x," = ",x(3),!
	} 
}
18 ноя 06, 16:29    [3419377]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

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

>>Пальцем покажите, пожалуйста. Вот на этом конкретном примере.

set x="^dft"
for  { set x=$q(@x) quit:x=""  quit:$qs(x,3)=76909 } 
write:x="" @x

set x="^dft"
for  { set x=$q(@x) quit:x=""  quit:$qs(x,3)>=53189 } 
if x'="" { set x(1)=$qs(x,1),x(2)=$qs(x,2),x=$qs(x,3)-1
	for  { set x=$o(^dft(x(1),x(2),x),1,x(3)) quit:x=""  quit:x>76909 
		w x," = ",x(3),!
	} 
}


Сдаюсь...
18 ноя 06, 16:41    [3419411]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

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

Несколько человек, несколько дней пытаются объяснить мне что запись в физическом блоке
^a(1,2,3,4)=0
соответствует логической записи
^a("1,2,3,4")=0
На этом птичьем языке совершенно непонятно, что из двух записей
^a(1,2,3,4)=0
^a("1,2,3,4")=0
одна почему-то физическая, а другая логическая...
Что тут скажешь? Они неправы. Пояснить? Хорошо, мне это не составит труда.
Итак, сравним дерево A:
^a
$ 1
| \ 
|  \        
$ 2  $ 3
|     \   
|      \
$ 3     $ 4
и дерево B:
^a
$---------$
 "1,2,3"   "1,3,4"
По-моему разница видна невооруженным глазом. Это то, что я уже несколько дней
пытаюсь объяснить нескольким людям. Продолжать или хватит?

Не нужно ничего оъяснять. Эти люди всё прекрасно понимают. Лучше перестаньте думать на этом птичьем языке.
В обоих случаях
^a(1,2,3)=0
^a(1,3,4)=0
и
^a("1,2,3")=0
^a("1,3,4")=0
ключами являются 1,2,3 и 1,3,4. И именно по этому ключу, или по его части, будет производиться поиск и спуск вниз в страницы с данными и их дальнейшее сканирование.
И B-дереву при поиске совершенно пофигу искать по составному ключу индексы 1,2 или искать по началу ключа "1,2". Результат будет один...
Вот тут
^a
$---------$
 "1,2,3"   "1,3,4"
Вы нарисовали вообще непонятно какую структуру. Точнее одну из возможных логических интерпретаций. Физически в В-дереве это будет лежать вот так
"1,2,3"
  "3,4"
Это ни что иное, как нарисованное Вами дерево. Спустившись до "1,2", можно взять "1,2,3". Или добежать до "3,4". Или добавить данные по ключу "1,2" (вставить значение, по первым двум измерениям, с индексами [1][2] в многомерном разреженном массиве) и получить от узла 2 ещё одну логическую ветку дерева и т.п.

pavelvp

Что и было подтверждено недавно в этом же топике :-) Да я и сам пробовал (сравнивал с ЛИНТЕР, Oracle, Sybase). Во всех случаях БД этих СУБД (таблица+индекс) получалась меньше на 10-30%, т.к. все эти СУБД используют B*-деревья.
Примеры в студию пожалуйста. Особенно в отношении Cache.
Цифры приводились ранее в этом же топике. На какой странице не помню. Где-то с полгода или год назад я чуток помацал Cache. Результаты также обсуждались на этом форуме. Искать сейчас неохота. Тогда сторонники Cache заявляли он компактности БД. В результате выяснилось, что при одинаковом объёме данных и схожей структуре БД Cache получалась либо такой же, либо даже больше. Про "таблица+индекс" это я описался. Хотел сказать только про индекс. Почему - другой вопрос. Может я что-то не так делал.
Но речь не о том, поэтому предлагаю в эту тему углубляться.


И еще. Цитата, так ловко урезанная Вами на самом деле выглядит следующим образом:
[quot ]
Ядро СУБД Cache использует B+-деревья для хранения данных. В терминах Cache каждое
такое дерево называется глобалом. Прямой доступ к структурам хранения осуществляется
с помощью языка Cache ObjectScript. На уровне языка Cache ObjectScript реализуется
многомерная модель данных, где глобал представляется многомерной переменной
произвольной размерности. По синтаксису языка Cache ObjectScript имя глобала
начинается с символа "^". После имени глобала в круглых скобках через запятую
указывается произвольное количество индексов. Компилятор осуществляет
преобразование всего множества индексов в ключ B+-дерева.
(выделено мной). Знаете что пришло в голову мне относительно Вашей предприимчивости?

Тут я что-то не понял. Что это меняет? А по синтаксису M, что начинается с этого символа?
Вы о чём?
18 ноя 06, 16:49    [3419426]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
^a(1,2,3,4)=0

Это не одно и то же - не в логической не в физической структуре.

^a("1,2,3,4")=0


Как не одно и тоже массив одной и четырёх размерностей


В обоих случаях
^a(1,2,3)=0
^a(1,3,4)=0
и
^a("1,2,3")=0
^a("1,3,4")=0
ключами являются 1,2,3 и 1,3,4.


нет! это совершенно не одно ит тоже. Да и сортировка у вас будет разная. ибо
a(1,"2")=1
a(1,"2","3")=0
a(1," ",3)=1

b("1, ,3")=1
b("1,2")=1
b("1,2,3")=0

За "1,3,4" у "нас" обычно "растреливают"
18 ноя 06, 17:03    [3419457]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
>>Спустившись до "1,2", можно взять "1,2,3". Или добежать до "3,4"

А можно просто проверить существование уровня 1,2 и если его нет успокоится.

На "1,2,3" Вы как себе это представляете
18 ноя 06, 17:07    [3419466]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
Sergei Obrastsov
DocAl
Т.к. в этой ветке диалог ведётся чуть более конструктивно, задам этот вопрос тут. В свете описанных в соседней ветке занимательных приключений американца в... Каше, не мог бы Sergei Obrastsov, или кто-то другой, практикующий разработку с использованием этой системы, рассказать, как решаются вопросы с контролем версий, отладкой, бакапами?

1. Поскольку я работаю в одиночку, вопрос с контролем версий у меня не стоит. Знакомая фирма
использует CSV, вроде. Правда, примитивный контроль версий Cache ведет на уровне программ, но
это мелочь конечно.
2. Даже не знаю, что и сказать, никогда не задумывался. Слишком общий вопрос. Что конкретно интересует по отладке?
3. Backup развит достаточно хорошо. На физическом уровне (блоки БД) - полный и инкрементный.
Копирование глобалей ссылками/данными и блоками. Ну и плюс журналирование глобалей.


Сергей
можем подкинуть наш контролер версий (.int) -
помогает содержать м-хозяйство в относительном порядке
( CACHE , MSM )
18 ноя 06, 17:20    [3419500]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ptn
нет! это совершенно не одно ит тоже. Да и сортировка у вас будет разная. ибо

Это может у вас будет разная.
У меня будет такая, какую я захочу. Хотите такая, хотите сякая.
Захочу, чтобы пробел был больше - будет больше. Захочу меньше - будет меньше.
Захочу - будет равен '2'.
Пусть будет хоть в хексе, хоть в юникоде, хоть в ханжи, хоть блин сами придумайте свою кодировку.
Ptn
>>Спустившись до "1,2", можно взять "1,2,3". Или добежать до "3,4"

А можно просто проверить существование уровня 1,2 и если его нет успокоится.

На "1,2,3" Вы как себе это представляете
Думаю точно так же, как и вы. Послушайте, если вас так напрягают эти кавычки - так уберите их нафиг. Это не волновая функция, так что можно просто сократить :-)
18 ноя 06, 17:45    [3419561]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
pavelvp
>>Это может у вас будет разная.

именно поэтому я писал кому то про ЖЕСТЬ. :) На логическом уровне да - именно то что вы пишите У меня будет такая, какую я захочу. Хотите такая, хотите сякая.

только спорить о логическом уровне IMXO смысла нет.

>>Послушайте, если вас так напрягают эти кавычки - так уберите их нафиг. Это не волновая функция, так что можно просто сократить :-)

Тогда всЁ о чем говорил Сергей теряет физический смысл. А спорить о логическом смысла нет.

Всё есть один запрос (обращение). Всё выбирается ядром, согласно плану. Время выполнения запроса конечно ;)
18 ноя 06, 17:59    [3419602]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
DocAl
А вы не читали ту ссылку? (http://thedailywtf.com/forums/post/60692.aspx) Автор утверждает, что
архитектура хранения кода не позволяет пользоваться системами контроля версий.


позволяет. мы используем итеграцию с VSS через com-объекты

DocAl

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


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

DocAl

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


абсолютно никаких проблем - автор бредит

что еще прокомментировать?
18 ноя 06, 19:29    [3419765]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
pavelvp
Croaton
"Физиология" внутреннего хранения: http://drus.boom.ru/StoreCache.pdf
Ну нет тут индексов в понимании РСУБД. Так-же как скачков к данным по логарифму. Так как соседние блоки в курсе друг о друге....


ГЫ-ГЫ-ГЫ!!!!!!! Не, ну это просто цирк, господа! Ещё один клоун :-)))
Ох я и поржал, аж до слёз... :-)))

...

Эти ссылки нужны не для контроля целостности дерева! Они нужны только, и только для того, чтобы обеспечить быстрое выполение сканирования дерева, и ни для чего больше!


по статье видно что автор явно далек от деталей реализации, поэтому не принимайте близко к сердцу

pavelvp

Комментарий для профессионалов (ламерам почитать тоже рекомендуется).
Ребята, тут многое проясняется :-) Хотя может автор статейки и гонит про B+-tree, может но такой же ламер, может там всё-таки B*-... Но обратите внимание! Не B*- используется, а B+-tree.


в документации ничего не написано про B+ или B*, а только это
Globals are stored within physical files using a highly optimized structure. The code that manages this 
data structure is also highly optimized for every platform that Caché runs on. 
These optimizations ensure that operations on globals have high throughput (number of operations per unit of time), high concurrency (total number of concurrent users), efficient use of cache memory, and require no 
ongoing performance-related maintenance (such as frequent rebuilding, re-indexing, or compaction).
The physical structure used to store globals is completely encapsulated; applications do not worry about physical data structure in any way.
Globals are stored on disk within a series of data blocks; the size of each block (typically 8KB) is determined when the physical database is created. 
To provide efficient access to data, Caché maintains a [b]sophisticated B-tree-like structure[/b] that uses a set of pointer blocks to link together related data blocks. Caché maintains a buffer pool — an in-memory cache of frequently referenced blocks — to reduce the cost of fetching blocks from disk.
While many database technologies use B-tree-like structures for data storage, Caché is unique in many ways:

    *
      The storage mechanism is exposed via a safe, easy-to-use interface.
    *
      Subscripts and data are compressed to save disk space as well as valuable in-memory cache space.
    *
      The storage engine is optimized for transaction processing operations: inserts, updates, and deletes are all fast. Unlike relational systems, Caché never requires rebuilding indices or data in order to restore performance.
    *
      The storage engine is optimized for maximum concurrent access.
    *
      Data is automatically clustered for efficient retrieval.

однако я уточню этот момент в intersystems
18 ноя 06, 19:45    [3419798]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
pavelvp
Ptn
нет! это совершенно не одно ит тоже. Да и сортировка у вас будет разная. ибо

Это может у вас будет разная.
У меня будет такая, какую я захочу. Хотите такая, хотите сякая.
Захочу, чтобы пробел был больше - будет больше. Захочу меньше - будет меньше.
Захочу - будет равен '2'.
Пусть будет хоть в хексе, хоть в юникоде, хоть в ханжи, хоть блин сами придумайте свою кодировку.


Вы считаете что в каше нельзя сделать произвольный collation? Уверяю Вас - можно.
18 ноя 06, 19:50    [3419813]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Pnt
Guest
Это написано у Кирстена.

Объектно-ориентированная разработка приложений в среде постреляционной СУБД Cach'e

7.1.3 К вопросу об организации хранения данных в глобалах
7.1.3.1 B* деревья

Cach'e сохраняет глобальные данный в B* деревьях. Подробнее описание основных принципов хранения со множеством примером подробно изложены в приложении С к книге Cach'e Programming Guide.
....

(c) Вольфганг Кирстен
18 ноя 06, 19:57    [3419825]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

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

Предпосылка: утверждение, что таблица с двумя полями адекватна дереву.
Дано: дерево. рабочее, с развешанными внутри перекрестными ссылками для повышения производительности.
Получено: таблица с двумя полями.
Вопрос 1: адекватны ли они внешне?
Ответ 1: допустим.
Вопрос 2: адекватны ли они по производительности?
Ответ 2: нет. таблице необходимы дополнительные индексы. в дереве они уже есть.

Хе-хе. А как-будто они Вам не нужны? Нет, любезный, адекватность полная. И соответсвенно выводы Ваши - неадекватные. Посмотрите повнимательней что я тогда написал, Вы часто с ваводами торопитесь.
Sergei Obrastsov

Вывод 1: нефиг сравнивать.
Вывод 2: нефиг говорить необдуманно.
Вывод 3: нефиг прятаться за возможностями системы. если речь идет о структуре, то и
надо говорить о ней, как о полноценном объекте. а иначе - Вывод 1.

P.S. Прошу прощения за резкость ответа.

Да ничего, потерплю, лишь бы Вы истину познали

Sergei Obrastsov
Давайте отвлечемся на минутку. Меня достало слушать про "дублируете данные". РСУБД не пишет в индексах истинные значения полей, я правильно Вас понял? А что же там тогда пишется? Только, пожалуйста, избавьте меня от сентенций типа "индексы не входят в логическую модель данных

Не, я таких умных слов (про сентенции) не знаю. Но мне кажется одно дело когда я сам должен заботиться о том какие данные записывать и другое дело, когда это делает сам сервер.
А Вас кстати не удивляет что даже Фокс, да что Фокс - еще DBase в 80-х - сам индексы поддерживал, а Каше не может?
Что касается чего там внутри индекса делается - я к этому доступа всё равно не имею и делали тот механизм разработчики, которые гораздо квалифицированней меня, да и тестеров было страшно представить сколько

Sergei Obrastsov
...Просто потому, что я не лимитирован способом хранения данных и потому что деревья представляют в этом плане другие возможности в организации хранения
Дык продемонстрируйте какие! Заранее обязуюсь представить Ваши возможности в таблице из двух полей. Могу даже взять повышенные обязательства - таблица может быть из одного поля. Только задучу опишите по русски, а не на М


Ptn
нет! это совершенно не одно ит тоже. Да и сортировка у вас будет разная. ибо
a(1,"2")=1
a(1,"2","3")=0
a(1," ",3)=1

b("1, ,3")=1
b("1,2")=1
b("1,2,3")=0

За "1,3,4" у "нас" обычно "растреливают"
Скоро тогда за М будет рассреливать
А в чем разница то? Неубедительный ответ. В обоих случаяю осуществляется индексный поиск по ключу. Кавычки на это никак не влияют. По этому я заявляю что это одно и тоже. Ваши аргументы?

И еще вопрос - тот Ваш конкретный пример (вообще-то ЖЕСТЬ (С) Gluk) - там идёт фуллскан или нет?
19 ноя 06, 02:16    [3420393]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Коллеги,

Мы в результате пришли к выводу что Каше хранит данные в B* деревьях, так что никаких принципиальных преимуществ данной схемы хранения по сравнению с Оракловой реализацией Index-Organized Table я не вижу. Это если действительно Каше хранит данные в B* как утверждает Вольфганг Кирстен, а не в B+ как утверждает г-н Плотников А.П.

В лагере специалистов по Каше и М-системам еще имеются возражения по данному вопросу, или у нас консеснус и данный вопрос можно закрывать?
19 ноя 06, 03:00    [3420409]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 35 36 37 38 39 [40] 41 42 43 44 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить