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

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

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

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

Вы вообще читаете то, что сами пишете? Я еще раз повторю: в дереве есть все нужные индексы.
Я их туда уже заложил. Для обеспечения производительности.
Вы переносите его в свою таблицу и заявляете, что Вам нужны дополнительные. Где адекватность?

SergSuper

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

А Вы не отвлекайтесь на эти мелочи. Нравится Вам, что ядро СУБД об этом заботится, ну и славно.

SergSuper

А Вас кстати не удивляет что даже Фокс, да что Фокс - еще DBase в 80-х - сам индексы поддерживал, а Каше не может?

Не не может, а не делает этого. По многим причинам. Которые уже достаточно здесь обсуждали.

SergSuper

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

Увиливаем от ответа?
19 ноя 06, 03:23    [3420418]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
Зл0й
Коллеги,

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

В лагере специалистов по Каше и М-системам еще имеются возражения по данному вопросу, или у нас консеснус и данный вопрос можно закрывать?


вопрос закрыть
кашистов - по лагерям
и нет проблем
19 ноя 06, 03:23    [3420419]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

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

У меня возражений нет. Речь не только об IOT, но и о хранении стандартных индексов в Oracle,
которые суть те же B*.
19 ноя 06, 03:28    [3420420]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sgt.Pepper
Member

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

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

M-ACID в действии?

Занимательно о переводах...

Покажите адекватную структуру на SQL, говорит г.Obrastsov.
Softwarer расчехляет SQL, играет в Маршака, если представить, что Sergei Obrastsov Шекспир...

Но нет!
Ах Вы еще и индексы у себя накатали? Не было такого уговора!

Неадекватно Маршак работает!

Как же с этими проблемами разбирается Шекспир (он, понятное дело, не опускается до переводов на русский)?
Очередной ответ - созданием нужного индекса конечно

Может он шутит?
Никак нет!
Я уже 100 раз сказал, что создаю индексы самостоятельно

Автор имеет суровый опыт разработки быстрых приложений. У него десять деревьев и одна могучая глобаль, поскольку я работаю в одиночку (с).
Это проект "Платежки для Балабановской спичечной фабрики", надо полагать.
Отсутствие фантазии тоже имеет место быть:
Простите, не могу представить. Даже 500 представить не могу

____________________________

Все то же солнце ходит под луной,
Но и оно не блещет новизной (с) Шекспир
19 ноя 06, 08:52    [3420465]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
SergSuper
>>А в чем разница то? Неубедительный ответ.

Это чисто ваши проблемы - пример - он - демонстрации для.

>>В обоих случаяю осуществляется индексный поиск по ключу.

Вы как и остальные оппоненты завязались на логический уровень ?
Первый случай - стандартный М случай - с полной поддержкой обработки со стороны языка. Поиск, определение, запись.

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

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

PS: Да, в целом согласен в обоих случаях запрос таки будет выполнен :lol: а цена никого в логике
не волнует.

>>По этому я заявляю что это одно и тоже. Ваши аргументы?

Да заявляйте сколько угодно :) ДЛЯ РУСБД-ков вполне может быть что и так. Но мы не РСУБД-ники и база у нас не РУСБД-ая и язык в ней не РУСБД-ный.

>>И еще вопрос - тот Ваш конкретный пример (вообще-то ЖЕСТЬ (С) Gluk) - там идёт фуллскан или нет?

Если вы РУСБД и как и Gluk в ~ видите строку - то у вас будет фуллскан, если там НЕ строка НО индексы фуллскана в большинстве случаев можно избежать.

Но Вы ведь декларировали что для вас это одно и то же ?, ну тогда да никакой разницы в ковычках :lol:

ЗЫ: И еще - я писал про кол-во таблиц у "нас" - падавляющее большинство требуют только одного - индекс нужно задекларировать - поддерживает его Каша. Так что не нужно сказку про страшные индексы.
Хотя если возникнет необходимость я могу это сделать и руками.
19 ноя 06, 10:23    [3420520]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
mumps-ист
Guest
Sergei Obrastsov
У меня возражений нет. Речь не только об IOT, но и о хранении стандартных индексов в Oracle, которые суть те же B*.


Сергей, именно об этом Вам и говорят в течение всего топика. Буду говорить про стандартный mumps, так как SQL и объекты в Cache не выдерживают никакой критики и нервно курят в стороне при сравнении с любой РСУБД.
1. Oracle поддерживает не одну схему физ. хранения данных и около десятка вариантов организации индексов (пусть знатоки Oracle уточнят). Cache поддерживает ОДНУ физ. структуру хранения данных (будем считать , что это B*-tree). Если вы считаете, что B*-tree - это лучший вариант физ. хранения данных для всех случаев - вопросов больше нет. Пример с хеш-индексом Вы приводили, только заметьте, что это уже ЛОГИЧЕСКИЙ хеш-индекс - он вас не выводит на блок с данными, он вас выводит на индекс, по которому далее нужно найти запись через B*-tree.
2. Реализовывать read-commited и т.п. в mumps нужно руками. Вопрос: какую схему блокировок Вы в используете своей рабочей системе, когда делаете выборку данных? Блокируете отдельные записи/весь глобал/части глобала на время выборки?
3. Самая сложная часть любой СУБД - это оптимизатор запросов. Это то, над чем работают многие программисты Oracle. Microsoft десятки лет. При использовании mumps это целиком перекладывается на программиста. Яркий пример - полное неведение многих специалистов М технологии по поводу того, что при низкой селективности индекса full-scan эффективнее, чем использование индекса, если в выборку попадает более 15% всех записей.
Сложность данного компонента хорошо видна на примере реализации SQL в Cache - при ислпьзовании любых звпросов сложнее простого селекта идет рекомендация использовять прямой доступ - и это при том, что внятной документации по правилам блокировок и т.п. в реализации SQL в Cache - нет.
4. Пресловутая сложность админстрирования как раз и заключается в наличии большого кол-ва альтернатив для хранения данных, хранения индексов, настройки оптимизатора и т.п. Если все, что умеет делать СУБД - это писать и читать B*-tree, то администрирования действительно не нужно.

В общем, покупая Cache за цену Oracle вы покупаете около 10% функциональности Oracle. И берете на себя обязательства по разработке оставшегося своими руками.
Я не призываю Вас бросить mumps и занятся Oracle. Очевидно - если в компании есть специалист по mumps - он никогда не будет решать задачу на РСУБД и наоборот. Но очень рекомендую почитать книги по физ. устройству РСУБД, оптимизатору запросов, алгоритмам select, join и т.п. - тогда станет понятно, какой объем работа на Вас перекладывает InterSystems и насколько ваше самописное решение далеко от оптимального.
19 ноя 06, 10:26    [3420525]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ptn
pavelvp
>>Это может у вас будет разная.

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

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

<skipped>

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

Я говорю о физическом и только о физическом уровне. О логическом говорите вы и Сергей. Это вы выдумываете деревеья и многомерные разреженные массивы.
В моих словах - только физика.

Rus000

Вы считаете что в каше нельзя сделать произвольный collation? Уверяю Вас - можно.

Я? С чего Вы это взяли? Это Ptn про неправильную сортировку песни пел.

Ptn

SergSuper
>>А в чем разница то? Неубедительный ответ.

Это чисто ваши проблемы - пример - он - демонстрации для.

>>В обоих случаяю осуществляется индексный поиск по ключу.

Вы как и остальные оппоненты завязались на логический уровень ?

<skipped>

Если вы РУСБД и как и Gluk в ~ видите строку - то у вас будет фуллскан, если там НЕ строка НО индексы фуллскана в большинстве случаев можно избежать.

Никакого логического уровня. Вам говорят и физике. Не важно, что у вас 1,2,3 и "1,2,3". И в том и в другом случае ключ один и тот же. И в первом и во втором случае если не известно начало, т.е. 1,2 или "1,2", до 3 или "3" вы никак не доберётесь без сканирования.

Ребзо! Кажись до меня начинает доходить где собака порылась...
Ведь в M-системах 1,2,3 это типа индексы массива. У них же нет множеств и нет выборок. Они работают со значениями. Можно только двигаться по индексам и перебирать значения.
Т.е. мы никак не можем реализовать операцию типа LIKE '1,2,%'... кроме как выполнить fullscan.
Это так? Если это так, то тему можно закрывать. Тогда становится совершенно очевидно, что для M-систем ^a(1,2,3) и ^a("1,2,3") - это действительно две большие разницы.
Т.е. физически это одно и то же, а логически - в рамках возможных операций с глобалом - нет.
Т.о. получается, что набор допустимых операций с глобалом не позволяет использовать всех возможностей поддерживаемых физическим уровнем хранения :-)
Хотя нет. Можно - ^Студент('И','В','А','Н','О','В'). Тогда можно LIKE сделать быстро.
Или меня не туда занесло?
19 ноя 06, 17:43    [3421189]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Sergei Obrastsov
Вы вообще читаете то, что сами пишете? Я еще раз повторю: в дереве есть все нужные индексы.
Я их туда уже заложил. Для обеспечения производительности.

Может Вы где-то чего-то и закладывали, но вот здесь - я их не вижу. Не откажите в любезности показать где там индекс для поиска по 3-ему или 2-му уровню?
Може ссылку не кликать, я сюда скопирую Ваш скрипт
^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")=

Что касается ответа волнует ли меня что сам сервер данные дублирует - ну по-моему ответил как смог. Не волнует. У меня свои алгоритмы работы с БД, у него(у сервера) свои алгоритмы выборки данных. Задачи несколько разные.


Ptn
Если вы РУСБД и как и Gluk в ~ видите строку - то у вас будет фуллскан, если там НЕ строка НО индексы фуллскана в большинстве случаев можно избежать.

Ничё не понял. Ответ тут может быть только однозначный - да или нет. Как можно избежать если нет дополнительных индексов?
А логический или физический уровень - я не задумывался. Критерий - скорость выборки, вернее как она делается - по индексу или перебором.

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

pavelvp

Ребзо! Кажись до меня начинает доходить где собака порылась...
Ведь в M-системах 1,2,3 это типа индексы массива. У них же нет множеств и нет выборок. Они работают со значениями. Можно только двигаться по индексам и перебирать значения.
Т.е. мы никак не можем реализовать операцию типа LIKE '1,2,%'... кроме как выполнить fullscan.
Это так? Если это так, то тему можно закрывать. Тогда становится совершенно очевидно, что для M-систем ^a(1,2,3) и ^a("1,2,3") - это действительно две большие разницы.
Т.е. физически это одно и то же, а логически - в рамках возможных операций с глобалом - нет.
Т.о. получается, что набор допустимых операций с глобалом не позволяет использовать всех возможностей поддерживаемых физическим уровнем хранения :-)
Хотя нет. Можно - ^Студент('И','В','А','Н','О','В'). Тогда можно LIKE сделать быстро.
Или меня не туда занесло?

Точно! Наконец-то я понял почему им это непонятно! Но это говорит о том что им этого и не понять...
20 ноя 06, 00:16    [3421785]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ЛП
Guest
mumps-ист
В общем, покупая Cache за цену Oracle вы покупаете около 10% функциональности Oracle. И берете на себя обязательства по разработке оставшегося своими руками.

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

Пока жив российский лох... (с)
20 ноя 06, 00:50    [3421801]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Croaton
Member

Откуда:
Сообщений: 11
ЛП
mumps-ист
В общем, покупая Cache за цену Oracle вы покупаете около 10% функциональности Oracle. И берете на себя обязательства по разработке оставшегося своими руками.

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

Пока жив российский лох... (с)


Боян длиною в тридцать лет....
http://www.citforum.ru/database/digest/codd_1.shtml
"Конечно, сейчас битва между реляционным и сетевым подходами кажется древней историей. (Победили хорошие парни.) "

Хорошие парни в очередной раз победили педер..ов. Пошел водит хороводы вокруг Кодда
20 ноя 06, 07:13    [3421948]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
pavelvp

>>В моих словах - только физика.

Пальцем ткните да - и где я о логике говорю - наверное в примерах :)

>>Никакого логического уровня. Вам говорят и физике. Не важно, что у вас 1,2,3 и "1,2,3".

Это для ВАС не важно - а для НАС очень важно - иммено из-за ФИЗИЧЕСКОГО уровня

ключ 1 не равен ключу "1,2,3"
ключ 2 не равен ключу "1,2,3"
ключ 3 не равен ключу "1,2,3"
три уровня не равны одному.
20 ноя 06, 08:40    [3422048]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
>>Т.е. мы никак не можем реализовать операцию типа LIKE '1,2,%'... кроме как выполнить fullscan.
>>Это так?
Нет это не так - фулскана не будет. Вы забываете что Сергея таблица на ПРЯМОМ доступе

3-размерности
 set x="" for { set x=$o(a(1,2,x)) quit:x=""  w x,! }
1-размерность
 set x="a(1,2)" for { set x=$o(@x) quit:x=""  quit:'(($qs(x,1)=1)&&($qs(x,2)=2) w x,! }

>>Тогда становится совершенно очевидно, что для M-систем ^a(1,2,3) и ^a("1,2,3") - это действительно две большие разницы.

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

Либо, при наличии ОБЫЧНОЙ таблицы, тупо писать
 
&SQL(SEELCT Name FROM Test.Z where Code Like '1,2,%')
20 ноя 06, 08:49    [3422075]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
ЛП
mumps-ист
В общем, покупая Cache за цену Oracle вы покупаете около 10% функциональности Oracle. И берете на себя обязательства по разработке оставшегося своими руками.

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

Пока жив российский лох... (с)


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

впарить что-либо кому-либо у нас в Латвии проблематично -
рынок ломится от программ, a госструктуры - не наш хлеб.
крупных заказов вообще единицы - притом все давно схвачено акулами

если будет лучше и конкурентнее на SQL-перейдем с MUMPSa на SQL
кушать то хочеца

пока - нет резона
MUMPS-лучше
20 ноя 06, 09:49    [3422262]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Ptn
Нет это не так - фулскана не будет. Вы забываете что Сергея таблица на ПРЯМОМ доступе

А можно здесь чуть поподробней?
Что такое ПРЯМОЙ доступ и как он позволяет избежать фуллскана?
Если мне нужно просканировать миллион записей, то какая разница прямой это будет доступ или нет - читать то всё рано придётся. Где я неправ?
20 ноя 06, 10:30    [3422497]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
pavelvp
Т.е. мы никак не можем реализовать операцию типа LIKE '1,2,%'... кроме как выполнить fullscan.
Это так?

Кому как. Вроде бы коран не запрещает использовать $o() чтобы получить следующее значение в индексе которое сортируется после "1,2," И остановить проход если ключ не начинается на "1,2,"
Это если я правильно ошибаюсь соответствуюет примерно range scan.
20 ноя 06, 11:03    [3422711]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ptn
>>В моих словах - только физика.

Пальцем ткните да - и где я о логике говорю - наверное в примерах :)

>>Никакого логического уровня. Вам говорят и физике. Не важно, что у вас 1,2,3 и "1,2,3".

Это для ВАС не важно - а для НАС очень важно - иммено из-за ФИЗИЧЕСКОГО уровня

ключ 1 не равен ключу "1,2,3"
ключ 2 не равен ключу "1,2,3"
ключ 3 не равен ключу "1,2,3"
три уровня не равны одному.
ВАС, НАС...
Понимаете ли в чем дело, B*-tree позволяет искать не только на равенство ключа...
20 ноя 06, 11:30    [3422954]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Зл0й
Sergei Obrastsov

Достаточно блокировки. Причем эта возможность блокировки появилась в стандарте M еще 1977-го года.

Если абстрагироваться от реализации то блокировка - частный (вырожденный) случай семафора. Блокировки чего конкретно? Как с deadlock'ами будем бороться если блокировки различной гранулярности? Опять что ли пишем нечто подобное оракловому ядру "ручками"? Повторять сакраментальный вопрос "Зачем писать то, что давным-давно написано и отлажено" надоело.


+1 Помимо дидлоков, Oracle сами блокировки хранит по хитрому (в блоках данных), с чего имеет вполне определенные бенефиты. Тоже будем реализовывать ? Про версионность (которая есть уже и в MS SQL) промолчу
20 ноя 06, 11:31    [3422965]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
Простите, не могу представить. Даже 500 представить не могу. Это что, логическая схема такая?
Вы серьезно?


Более чем. То что Вы не можете этого себе представить уже говорит о многом
20 ноя 06, 11:35    [3423005]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
SergSuper
Ptn
Нет это не так - фулскана не будет. Вы забываете что Сергея таблица на ПРЯМОМ доступе

А можно здесь чуть поподробней?
Что такое ПРЯМОЙ доступ и как он позволяет избежать фуллскана?
Если мне нужно просканировать миллион записей, то какая разница прямой это будет доступ или нет - читать то всё рано придётся. Где я неправ?


Куда уж подробнее - я два варианта написал.

ПРЯМОЙ доступ это когда вы выбираете задачу, перечисляете данные и запросы к этим данным, выстраиваете структуру в глобале - прописываете хранимые процедуры для "внешнего" API, в процедурах пишите примерно то что я привел. И живете.
Как правило это особые таблицы с определенными задачами. То есть ПРЯМОЙ доступ удобне для записи и набора выборок. Для произвольных выборок он не особо подходить в этих случаях вы полагаетесь на план-движок встроенного SQL.

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

Если у вас задача такая "просканировать миллион записей" то разницы нет конечно же не какой.
Если же у вас для "сканирования" указан критерий и критерий укладывается в индексы - то фуллскана не будет. Пример я привел.

Где я не прав ?
20 ноя 06, 11:40    [3423051]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
pavelvp
Ptn
>>В моих словах - только физика.

Пальцем ткните да - и где я о логике говорю - наверное в примерах :)

>>Никакого логического уровня. Вам говорят и физике. Не важно, что у вас 1,2,3 и "1,2,3".

Это для ВАС не важно - а для НАС очень важно - иммено из-за ФИЗИЧЕСКОГО уровня

ключ 1 не равен ключу "1,2,3"
ключ 2 не равен ключу "1,2,3"
ключ 3 не равен ключу "1,2,3"
три уровня не равны одному.
ВАС, НАС...
Понимаете ли в чем дело, B*-tree позволяет искать не только на равенство ключа...


Понимаю - можете кстати процитироват меня где я утверждаю что нельзя ?

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

И не использовать их в живой М-системе - как минимум странно.
20 ноя 06, 11:45    [3423099]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Ptn
Типичная задача получения значения на некоторую дату - в таблице с временным параметром - например сетка неких тарифов. Код на М может занимать две строки.

Две - это очень много :)
select top 1 * from Tarif where date <=[некоторая] order by date desc 
20 ноя 06, 12:21    [3423510]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
Только понимаете ли в чем дело - по "дереву" мы бегаем на вполне конкретном языке М - которые для этого предлагает определенные механизмы доступа - в том числе и поиск.


Которые (механизмы) на физическом уровне превращаются в поиск в B-дереве и RangeScan.
Чудес-то не бывает :)

Кстати, реализация "хэш" таблицы на базе B-дерева прибила наповал.
Это был хороший зонтик, он только воды боялся (с)
20 ноя 06, 12:30    [3423586]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
SergSuper
Ptn
Нет это не так - фулскана не будет. Вы забываете что Сергея таблица на ПРЯМОМ доступе

А можно здесь чуть поподробней?
Что такое ПРЯМОЙ доступ и как он позволяет избежать фуллскана?

Сейчас поясню о чём речь. ПРЯМОЙ доступ тут конечно же совершенно ни при чём.
Разобрался в кракозябрах, которые Ptn привёл. Как тут кто-то говорил уже, наверное у них за каждый лишний символ расстреливают :-)
$o - это функция $order :-)
Что она делает описал ну я.
Слегка модифицированный для наших целей пример из доки.
SET ^data("1,1,")="a",^data("1,2,")="a",^data("1,2,3,")="c",^data("1,3,4,2")="g"
// Get first subscript
SET key=$ORDER(^data("1,2,"))
WHILE (key'="") {
WRITE key,!
// Get next subscript
SET key = $ORDER(^data(key))
}
У функции $order вообще-то три параметра. Второй параметр - direction.
Т.о. можно спозиционироваться в глобале по значению ключа и дальше бегать по нему туда-сюда.
Если искомого ключа нет, то возвращается следующий. В алфавитном порядке.

В примере приведённом Ptn
set x="a(1,2)" for { set x=$o(@x) quit:x=""  quit:'(($qs(x,1)=1)&&($qs(x,2)=2) w x,! }
он позиционируется на следующий ключ и смотрит чего смотрит, что там есть.
$QS - функция $QSUBSCRIPT(namevalue,intexpr).
Только мне кажется этом коде лажа какая-то есть... Попробовать не на чем.

ну я
pavelvp
Т.е. мы никак не можем реализовать операцию типа LIKE '1,2,%'... кроме как выполнить fullscan.
Это так?

Кому как. Вроде бы коран не запрещает использовать $o() чтобы получить следующее значение в индексе которое сортируется после "1,2," И остановить проход если ключ не начинается на "1,2,"
Это если я правильно ошибаюсь соответствуюет примерно range scan.

Да, Жень, я понял. Только теперь совсем непонятно, что же было непонятно для Sergei Obrastsov :-)
20 ноя 06, 12:37    [3423648]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ptn
Если же у вас для "сканирования" указан критерий и критерий укладывается в индексы - то фуллскана не будет. Пример я привел.

Где я не прав ?
Вы видимо в контекст беседы не совсем попали. Просто Sergei Obrastsov почему-то утверждал, что в M фуллскана не будет, а в РСУБД он почему-то будет...
Хотя я уже не уверен понимает ли здесь хоть кто-нибудь о чём вообще разговор :-)
Я вот, кажись, уже не понимаю :-)
20 ноя 06, 12:42    [3423700]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ptn
Только понимаете ли в чем дело - по "дереву" мы бегаем на вполне конкретном языке М - которые для этого предлагает определенные механизмы доступа - в том числе и поиск.

И не использовать их в живой М-системе - как минимум странно.
Да пожалуйста, используйте!
Странно то, что некоторые из здесь присутствующих M-программистов похоже о них не знают :-)
20 ноя 06, 12:52    [3423783]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 36 37 38 39 40 [41] 42 43 44 45 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить