Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 88 89 90 91 92 [93] 94 95 96 97 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
c127
Если ваша задача была привлечь к М технологиям новых пользователей, то вы ее успешно провалили, а теперь своим дурацким поведением ухудшаете свое положение.

Ну, во-первых, задачи у меня такой не было и нет, а во-вторых, она и не нужна. Атмосферу
нездорового интереса вокруг M создаете Вы сами (ну не один конечно), так что эта задача
перевыполняется и без моих усилий.
18 янв 07, 07:01    [3657557]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
И не надоело вам бодаться, томно гавкая?

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

Коллеги от М:
Основные претензии к вам на этом форуме, увы, относятся к вашей необразованности. Ну вот к сожалению не умеете вы в большинстве своём представить столь милую вашему сердцу технологию так, чтоб все затащились. Видел всего пару толковых обсуждений с технически грамотными и взвешенными комментариями от М разработчиков. Не надо сразу начинать кидаться окурками, когда вам говорят, что у М есть проблемы там-то и сям-то. Они есть, причём на самом базовом уровне (это уже не лечится (да-да-да, я помню, вы говорили, что можно влезть в самый нижний уровень и там всё ручками сделать, но оно вам надо?)). Проще говорить "зато мы делаем ракеты" и подробно объяснять почему именно эти ракеты так здорово летают. Вот как с этим злополучным станом прокатным. Только объяснять так, чтобы вас поняли. И учиться по-возможности. Применять технологию, не зная и не умея объяснить тонкостей её реализации иногда просто опасно - можно наступить на грабли. Как тот софт для госпиталей в штатах, что на ограничения цитриксовского метафрейма напоролся.

Отсутствие ЧАЛа кстати сказывается положительно. Ругани пока меньше не стало, но конструтива больше.
18 янв 07, 07:28    [3657572]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
andsm
То что приведено в качестве реализации хеш-индекса на М - не является им, потому что не обыспечивает константное время поиска. "^" это обращение к глобали, т.е. к B*-дереву. Как только такое обращение возникает, о константном времени поиска можно забыть


Уберите ^ .
В том же MySQL вроде как есть "временные" HASH индексы.

PS: Константное время поиска декларируется алгоритмом. А не реализацией.
18 янв 07, 07:59    [3657609]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Павел Воронцов
Не надо сразу начинать кидаться окурками, когда вам говорят, что у М есть проблемы там-то и сям-то. Они есть, причём на самом базовом уровне (это уже не лечится (да-да-да, я помню, вы говорили, что можно влезть в самый нижний уровень и там всё ручками сделать, но оно вам надо?)).


Мупсеры вполне осознают недостатки и ограничения технологии - только это увы не те недостатки про которые ведут речь РСУБД-ники.

Но это относится, увы, относится к их "необразованности" по данному вопросу.

Не нужно ходить по манастырю со своим уставом.

ЗЫ: wbr
18 янв 07, 08:17    [3657643]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
mumpsist
Guest
Ptn
andsm
То что приведено в качестве реализации хеш-индекса на М - не является им, потому что не обыспечивает константное время поиска. "^" это обращение к глобали, т.е. к B*-дереву. Как только такое обращение возникает, о константном времени поиска можно забыть


Уберите ^ .
В том же MySQL вроде как есть "временные" HASH индексы.

PS: Константное время поиска декларируется алгоритмом. А не реализацией.


Что Вам пытаются объяснить уже не одну страницу - если hash index поддерживается СУБД, то в большинстве случаев СУБД находит блок с записью за один дисковый IO. Конструкция ^A(X) - это нахождение блока, используя B дерево - соответственно, запись (в большинстве случаев) будет найдена за 3-4 дисковых IO (кеш в обоих случаях, естественно, не учитывается).
18 янв 07, 08:35    [3657685]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
mumpsist
Ptn
andsm
То что приведено в качестве реализации хеш-индекса на М - не является им, потому что не обыспечивает константное время поиска. "^" это обращение к глобали, т.е. к B*-дереву. Как только такое обращение возникает, о константном времени поиска можно забыть


Уберите ^ .
В том же MySQL вроде как есть "временные" HASH индексы.

PS: Константное время поиска декларируется алгоритмом. А не реализацией.


Что Вам пытаются объяснить уже не одну страницу - если hash index поддерживается СУБД, то в большинстве случаев СУБД находит блок с записью за один дисковый IO. Конструкция ^A(X) - это нахождение блока, используя B дерево - соответственно, запись (в большинстве случаев) будет найдена за 3-4 дисковых IO (кеш в обоих случаях, естественно, не учитывается).


Не нужно рассматривать детали реализации - они могут быть разными.
Уберите ^. Читайте блок самостоятельно.

Я просил не углубляться в физический уровень ибо - ваше "то в большинстве случаев СУБД находит блок с записью за один дисковый IO" - это логическое допущение.

Даже в том что индекс целиком помещатся в этот самый блок.

Не говоря уже о том что РСУБД все равно обращается к "FAT"-у блоков что бы найти нужный - алгоритм поиска в котором ??? Не подскажите ?

Говоря русским языком - IO преимущество РУСБД тут просто не факт.

Цифры вам Сергей привел, причем на своей реализации. Комментируйте их.
18 янв 07, 09:03    [3657775]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Мимопроходящий
Member

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

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

Ptn
P> Я просил не углубляться в физический уровень ибо - ваше
P> "то в большинстве случаев СУБД находит блок с записью за один
P> дисковый IO" - это логическое допущение.
сие "допущение" обеспечивается алгоритмом!
трудно объяснять слепому, какая она, радуга...
Ptn
P> Даже в том что индекс целиком помещатся в этот самый блок.

P> Не говоря уже о том что РСУБД все равно обращается к "FAT"-у
P> блоков что бы найти нужный - алгоритм поиска в котором ???
P> Не подскажите ?
м-да...
диагноз товарища саахова полностью подтвердился. (С)
в библятеку нах!
учиться!

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

Posted via ActualForum NNTP Server 1.3

18 янв 07, 09:10    [3657808]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Мимопроходящий

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

Ptn
P> Я просил не углубляться в физический уровень ибо - ваше
P> "то в большинстве случаев СУБД находит блок с записью за один
P> дисковый IO" - это логическое допущение.
сие "допущение" обеспечивается алгоритмом!
трудно объяснять слепому, какая она, радуга...
Ptn
P> Даже в том что индекс целиком помещатся в этот самый блок.

P> Не говоря уже о том что РСУБД все равно обращается к "FAT"-у
P> блоков что бы найти нужный - алгоритм поиска в котором ???
P> Не подскажите ?
м-да...
диагноз товарища саахова полностью подтвердился. (С)
в библятеку нах!
учиться!

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

Posted via ActualForum NNTP Server 1.3


Обажаю "общаться" с местными модерами - вежливость просто выплескивается на собеседников.

Ты не умничай - ты пальцем пакажи (с) ГэГ.

1. каким таким алгоритмом обеспечивается помещение всего индекса в один блок ?
2. какой алгоритм используется для поиска блоков соотвествующих таблиц и их индексов ?
3. как оно зависит от того что мы ищем ?
4. какое это отношение это имеет к АЛГОРИТМУ поиска по хэш индексу ?
5. как осуществляется поиск индекса в операторе set a=array(20) ?

Почему РСУБД-ники что бы сказать а у вас вот тут в "Б" трабла, долго и нудно заводять разговоры про "А", "Г" и "Д" - если всё равно разговор в конце концов скатывает к обсуждению работы "Б".

ЗЫ: not wbr
18 янв 07, 09:28    [3657895]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Vlad2005
Member

Откуда: Воронеж
Сообщений: 119
Sergei Obrastsov
Vlad2005
Немного о своем интересе к Каше - началось с того, что знакомые мужики из фин.упр. обладминистрации купившись на обещания по скорости взялись переписывать свою систему, что жила под DOSом на Каше.

Никогда Cache под DOS'ом не жила, так уж получилось. Это первое. Нафига переписывать систему,
которая якобы жила на Каше, снова на Каше, но уже под Windows, когда достаточно просто
перенести программы и данные? Это второе. Складывается впечатление, что либо Вы
непреднамеренно что-то путаете, либо преднамеренно врете. :)

Vlad2005

Я даже повелся, диск демо с этой Кашей выписал.

Ага, под DOS. :)

Vlad2005

Поглядел. Испытал нечто странное - слов много, но нифига не понятно, откуда такие характеристики.

А проверить не получилось? Ну там тестирование какое, чтобы слова с делом не расходились? :)

Vlad2005

Потом через год зашел в финуправление - а там уже вовсю Оракул енд Дельфи. Спрашиваю - "Почему?" - говорят - нереально за столь ограниченный срок реализовать что-то на этом. Причем про скорость сказали так, что можно было понять - вкапались ребятки по полной.

Это 1.5 года-то "столь ограниченный срок"? Да еще "втроем"?! Вы наверно шутите. :)
Насчет скорости поконкретнее можно? Мало ли что они там Вам сказали.

Vlad2005

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

Они просто молодцы, ночами еще небось трудились.


Во первых. Где это я сказал про Кашу под ДОСом? Первоначальная система была на xBASE наваяна с кучей доп библиотек (Clipper). За обвинение во вранье можно канделябром, как в приличном обществе принято. Про скорость уже врядли кто вспомнит - давно это было. Ну да ладно, спрошу. И еще - почему-то из опыта общения с людьми из Кашистского клана вытекает их обобщенный портрет - этакий разбитной малый, которому море по колено ;-)))
Во-вторых - по поводу ерничания насчет работы по ночам. Нет, обычная работа. Просто обьем огромный. Похоже, Вы его просто не представляете.
18 янв 07, 09:42    [3657976]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
цар
Guest
Vlad2005
Немного о своем интересе к Каше - началось с того, что знакомые мужики из фин.упр. обладминистрации купившись на обещания по скорости взялись переписывать свою систему, что жила под DOSом на Каше.
.


помиловать нельзя повесить

..систему, что жила под DOSом, ---перевести--- на Каше.
18 янв 07, 09:58    [3658078]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Vlad2005
Во первых. Где это я сказал про Кашу под ДОСом? Первоначальная система была на xBASE наваяна с кучей доп библиотек (Clipper).

Вот здесь. Цитатка еще раз:

Vlad2005

Немного о своем интересе к Каше - началось с того, что знакомые мужики из фин.упр. обладминистрации купившись на обещания по скорости взялись переписывать свою систему, что жила под DOSом на Каше.
(выделено мной)

Vlad2005

За обвинение во вранье можно канделябром, как в приличном обществе принято.

Оставлю эту фразу на Вашей совести.

Vlad2005

И еще - почему-то из опыта общения с людьми из Кашистского клана вытекает их обобщенный портрет - этакий разбитной малый, которому море по колено ;-)))

Вполне может быть. Это наверно потому, что они на практике ничего не умеют, но очень боятся, что об этом узнают.

Vlad2005

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

Куда уж мне, я ведь тоже этот, как его, "Кашист"
18 янв 07, 10:00    [3658100]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Vlad2005
Member

Откуда: Воронеж
Сообщений: 119
Sergei Obrastsov
Vlad2005
Во первых. Где это я сказал про Кашу под ДОСом? Первоначальная система была на xBASE наваяна с кучей доп библиотек (Clipper).

Вот здесь. Цитатка еще раз:

Vlad2005

Немного о своем интересе к Каше - началось с того, что знакомые мужики из фин.упр. обладминистрации купившись на обещания по скорости взялись переписывать свою систему, что жила под DOSом на Каше.
(выделено мной)

Vlad2005

За обвинение во вранье можно канделябром, как в приличном обществе принято.

Оставлю эту фразу на Вашей совести.

Vlad2005

И еще - почему-то из опыта общения с людьми из Кашистского клана вытекает их обобщенный портрет - этакий разбитной малый, которому море по колено ;-)))

Вполне может быть. Это наверно потому, что они на практике ничего не умеют, но очень боятся, что об этом узнают.

Vlad2005

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

Куда уж мне, я ведь тоже этот, как его, "Кашист"


Вам надо обьяснять, что значит "переписать", или сами поймете? У людей масса времени ушла на постановку задачи и согласование ТЗ и ТП, и что теперь, это дело ф топку? Именно на основании этих документов и началась работа. Повторюсь еще раз - без грамотного ТЗ, да и еще грамотно согласованного (дабы не упирались некоторые начальнички) работа чаще всего оканчивается грлмким крахом. Если ее обьем ессно, выходит за определенные рамки. А так, нечто простенькое - да пжалста, протокол сгласования - и вперед.

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

Еще раз - основное, что подвинуло меня вклиниться в дискуссию - не желание развести флуд, а просто уже не мог не написАть. И, самое главное, желание докопаться до истины.
18 янв 07, 10:16    [3658236]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Павел Воронцов
И не надоело вам бодаться, томно гавкая?

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

Коллеги от М:
Основные претензии к вам на этом форуме, увы, относятся к вашей необразованности. Ну вот к сожалению не умеете вы в большинстве своём представить столь милую вашему сердцу технологию так, чтоб все затащились. Видел всего пару толковых обсуждений с технически грамотными и взвешенными комментариями от М разработчиков. Не надо сразу начинать кидаться окурками, когда вам говорят, что у М есть проблемы там-то и сям-то. Они есть, причём на самом базовом уровне (это уже не лечится (да-да-да, я помню, вы говорили, что можно влезть в самый нижний уровень и там всё ручками сделать, но оно вам надо?)). Проще говорить "зато мы делаем ракеты" и подробно объяснять почему именно эти ракеты так здорово летают. Вот как с этим злополучным станом прокатным. Только объяснять так, чтобы вас поняли. И


были бы все сообщения в таком же взвешенном стиле как у Вас - в основном оппоненты агрессивны друг в отношении друга и редко когда конструктивны. В целом с оценкой ситуации в этом обсуждении согласен.
18 янв 07, 10:17    [3658244]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Vlad2005
Member

Откуда: Воронеж
Сообщений: 119
цар
Vlad2005
Немного о своем интересе к Каше - началось с того, что знакомые мужики из фин.упр. обладминистрации купившись на обещания по скорости взялись переписывать свою систему, что жила под DOSом на Каше.
.


помиловать нельзя повесить

..систему, что жила под DOSом, ---перевести--- на Каше.


Уже ответил.
18 янв 07, 10:18    [3658250]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
Ptn
andsm
То что приведено в качестве реализации хеш-индекса на М - не является им, потому что не обыспечивает константное время поиска. "^" это обращение к глобали, т.е. к B*-дереву. Как только такое обращение возникает, о константном времени поиска можно забыть


Уберите ^ .
В том же MySQL вроде как есть "временные" HASH индексы.

PS: Константное время поиска декларируется алгоритмом. А не реализацией.


нет, именно физической реализацией работы СУБД с дисковыми блоками.

Если хотите могу выписать из книги суть организации хэш-индекса.
18 янв 07, 10:19    [3658262]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Rus000
Ptn
andsm
То что приведено в качестве реализации хеш-индекса на М - не является им, потому что не обыспечивает константное время поиска. "^" это обращение к глобали, т.е. к B*-дереву. Как только такое обращение возникает, о константном времени поиска можно забыть


Уберите ^ .
В том же MySQL вроде как есть "временные" HASH индексы.

PS: Константное время поиска декларируется алгоритмом. А не реализацией.


нет, именно физической реализацией работы СУБД с дисковыми блоками.

Если хотите могу выписать из книги суть организации хэш-индекса.


тынц ?
Напомню что в ссылке c127 не было БД, а хэш-индекс был. В терминах статьи Сергей прав. IMXO.

Отсутствие ^ отменяет работу с дисковыми блоками.
Опять же кто мешает блоки читать самостоятельно ?

ЗЫ: Я знаю и понимаю про разную "организацию".
Но то что машина может называться "заднеприводной" только при налиии кордана и иначе никак слышу впервые.
18 янв 07, 10:35    [3658392]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Ptn
Почему РСУБД-ники что бы сказать а у вас вот тут в "Б" трабла, долго и нудно заводять разговоры про "А", "Г" и "Д" - если всё равно разговор в конце концов скатывает к обсуждению работы "Б".

ЗЫ: not wbr

В чужем глазу соринку увидеть кажный может. Кажный. А в своем бревно увидеть трудее.
Когда на вопросы про М, который я "хотел услышать не СУБД", Вы мне описывали Кашу, которую я и так считал СУБД (т.е. ясно, что не про Кашу спрашивал), Вас не беспокоило, что вместо "М" рассказываете про "К".
18 янв 07, 10:55    [3658583]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
vadiminfo
Ptn
Почему РСУБД-ники что бы сказать а у вас вот тут в "Б" трабла, долго и нудно заводять разговоры про "А", "Г" и "Д" - если всё равно разговор в конце концов скатывает к обсуждению работы "Б".

ЗЫ: not wbr

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


Каждый конешно. И про свои бревна я прекрасно осведомлен.

Беда в том что бревна у нас разные.
У нас нет таблиц - бревно.
У нас нет индексов- бревно.
У нас только B* деревья - бревно.
У нас нет FullScana - бревно.
У нас пользователей выгоняют в момент бэкапа - бревно.
У нас ACID - бревно. (забавно кстати написано по этому поводу на сайте GT.M)

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

Я работаю на "К" - а разговарию о "К". Всё что я рассказывал про "К" работает в большинстве "М".
А конкретно те вопросы, которые вы спрашивали, - им безралично в "К" они или в "М".
18 янв 07, 11:08    [3658687]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Стратегии соединения SQL Server

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

Имеют ли они права так называться в свете понаписаного выше ?

Где для работы с временным хеш-индексом имеет значение физическая организация блоков СУБД ?
18 янв 07, 11:16    [3658785]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2400
Блог
Ptn
Стратегии соединения SQL Server

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

Имеют ли они права так называться в свете понаписаного выше ?

Где для работы с временным хеш-индексом имеет значение физическая организация блоков СУБД ?
Ну нельзя же так долго и упорно ходить по одним и тем же граблям! Уважаемый, вы путаете хеш-индекс и кеширование в памяти. Очевидно, по созвучию. А не надо бы. Ну пожалуйста. Вам уже всё разжевали и в рот положили по десять раз, включая ваших же коллег-мампсистов. Хватит городить нелепости, будьте так добры!
18 янв 07, 11:25    [3658895]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Павел Воронцов
Ptn
Стратегии соединения SQL Server

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

Имеют ли они права так называться в свете понаписаного выше ?

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


Уважаемый.

Я не путаю - я все лишь утверждаю что и временный и хранимый - имеют полное право _называться_ именно хеш-индексом.

Неужели непонятно ? что _именно_ я оспариваю ???

С учетом того что по ссылке с127 рассматривается именно _временный_ хеш-индекс.

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

Я строго понимаю что РСУБД хеш-индекс это совсем не одно и тоже что М хеш-индекс.
Точно так же как не одно и то же Лисп и Паскаль.

Но как я уже говорил выше, с таким подходом - в М вообще нет ничего. (читай про бревна).
18 янв 07, 11:36    [3659017]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

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

А конкретно те вопросы, которые вы спрашивали, - им безралично в "К" они или в "М".

Нет не безразлично. Писал почему - это не безразлично даже для всех мумпсистов. Некоторые не признают Кашу., но любят М. Считают такое М без Каши супер СУБД, не согласны что она иерархичкая, и любая МД там есть. Разница великая есть.
Может я плохо спрашивал и это не понятно. Но это же Ваша фраза, что я хочу услышть что "М" не СУБД. Вы ее дважды сказали. Про "К" я этого услышать то не хотел. Вопросы то были про МД в М, а не в Каше.
18 янв 07, 11:39    [3659050]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
vadiminfo
Вопросы то были про МД в М, а не в Каше.

Вот до чего довела маркетинговая политика ИС. Дело в том, что Каше, это одна из реализаций М-системы, и противопоставлять М и К бессмысленно. SQL и объекты в Каше реализованы на тех же самых глобалах (разреженных многомерных массивах, В* деревьях) с помощью программ, написанных на языке М (ну называется он в Каше ObjectScript, ну расширен он относительно последнего стандарта ANSI в плане синтаксиса, ну прикрутили к нему Бэйсик чтобы новичков заманить, но суть дела от этого не меняется). Это, кстати, подтверждает, что в М-системе можно реализовать любую модель данных (хотите реляционную, так пожалуйста, таблички и SQL для доступа, хотите объектную - ObjectScript в рамках объектных его расширений). Но прежде всего, в глубине своей, это М !
18 янв 07, 12:01    [3659351]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
vadiminfo
Ptn

А конкретно те вопросы, которые вы спрашивали, - им безралично в "К" они или в "М".

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


В сейчас, если честно, я вас не понял.

Кто-то любить Borland Builder, кто-то тепрпеть не может VC++.
Кто-то обожал Watcom а кто-то gcc.

C/С++ здесь при чем ?

Какая то разница великая в этом есть ?

Я указал что М есть команды ЯЗЫКА которые выполняют роль управления БД. Как вы сей факт интерпретируете я знать не могу.
Могу только озвучивать свою точку зрения.

МД что в Каше что в М - разреженные многомерные массивы - уже говорил.
18 янв 07, 12:04    [3659391]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
mumpsist
Guest
Ptn

Отсутствие ^ отменяет работу с дисковыми блоками.

Не думаю, что работа с локалом гарантирует, что диск не используется. Вам же доступна операция merge a = ^a для размера глобала, превышающего размер оперативной памяти? Скорее всего, использование локала говорит говорит о том, что СУБД постарается не использовать диск.

Ptn

Опять же кто мешает блоки читать самостоятельно ?

Если расскажете, как на М (Cache) обратиться напрямую к блоку, буду признателен. И как вы получите номер блока, к которому нужно обратиться?

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

Собственно, вопрос не в том, как устроены алгоритмы. Просто где-то в обсуждении был вопрос о том, зачем в некоторых РСУБД по 10 видов физ. организации индексов. И хеш-индекс - хороший пример того, что для определенного вида задач организация данных на диске в виде В-дерева (единственная в Cache) - не самая эффективная.
18 янв 07, 12:16    [3659500]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 88 89 90 91 92 [93] 94 95 96 97 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить