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

Откуда:
Сообщений: 673
SergSuper
Две - это очень много :)
select top 1 * from Tarif where date <=[некоторая] order by date desc 
s t 1 * f Tarif w date <=[некоторая] o date d;
:-)))
20 ноя 06, 12:56    [3423807]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
SergSuper
Ptn
Типичная задача получения значения на некоторую дату - в таблице с временным параметром - например сетка неких тарифов. Код на М может занимать две строки.

Две - это очень много :)
select top 1 * from Tarif where date <=[некоторая] order by date desc 


Вторая это quit (значение) -можно записать и за одну.

Даже две строки на М - будут на порядок быстрее того что вы написали :)
 new rate quit:$o(^Tarif(ID,[некоторая]+1),-1,rate)'="" rate 
 quit 0

Тут всего два "атамарных" оператора поиск и возврат. Две P-команды для байт машины. Никаких сортировок, никаких переборов.

Посмотри план своего запроса - оцени время для его выполнения.

PS: На логическом уровне ничья :) - с той лишь разницей что если мне будет лениво я точно также могу написать
select top 1 * from Tarif where date <=[некоторая] order by date desc
20 ноя 06, 13:02    [3423882]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
pavelvp
Ptn
Если же у вас для "сканирования" указан критерий и критерий укладывается в индексы - то фуллскана не будет. Пример я привел.

Где я не прав ?
Вы видимо в контекст беседы не совсем попали. Просто Sergei Obrastsov почему-то утверждал, что в M фуллскана не будет, а в РСУБД он почему-то будет...
Хотя я уже не уверен понимает ли здесь хоть кто-нибудь о чём вообще разговор :-)
Я вот, кажись, уже не понимаю :-)


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

о чем Он и писал
[q=Sergei Obrastsov] Я их туда уже заложил. Для обеспечения производительности.[/q]
и даже выделил!

Ему же для контр-примера сказали о таблицах с двумя полями - СКАЗАВ что индексы можно добавить ПОТОМ. И пошло-поехало про логический уровень ИНДЕКСОВ.

Если их НЕ добавить в РУСБД и будет фуллскан.

Фишка в том что в структуру Сергея добавлять уже ничего не нужно.
20 ноя 06, 13:09    [3423967]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
pavelvp
У функции $order вообще-то три параметра. Второй параметр - direction.
Т.о. можно спозиционироваться в глобале по значению ключа и дальше бегать по нему туда-сюда.
Если искомого ключа нет, то возвращается следующий. В алфавитном порядке.

1. По стандарту - не три, а два параметра, третий - это расширение от Интерсистемс.
2. $o не позиционируется, а выдает всегда следующий. Либо после либо перед.
3. Не в алфавитном порядке, а в индексной сортировке, в порядке, определенном collation. Алфавитный - это частный случай, причем далеко не по умолчанию.
Кстати, намек: между двумя обращениями к $o могут пройти вставки данных из других процессов, так что выдача будет не обязательно всех подряд, а только тех, кто были следующими на момент обращения.

set x="a(1,2)" for { set x=$o(@x) quit:x=""  quit:'(($qs(x,1)=1)&&($qs(x,2)=2) w x,! }
Тут вместо $o надо $q.
20 ноя 06, 13:23    [3424071]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ptn
Ему же для контр-примера сказали о таблицах с двумя полями - СКАЗАВ что индексы можно добавить ПОТОМ. И пошло-поехало про логический уровень ИНДЕКСОВ.

Если их НЕ добавить в РУСБД и будет фуллскан.

Фишка в том что в структуру Сергея добавлять уже ничего не нужно.
Ты знаешь, мы тут не такие тупые как тебе кажется. Совершенно естесственно, если в таблице из двух полей первое поля является ключом, было бы неплохо если бы по этому полю был построен индекс.
Это также естесвенно как и для эффективного поиска в структуре
^a(1)="Иванов"
^a(2)="Петров"
^a(3)="Сидоров"
Сидорова , эти данные нужно добавить в индекс.
Разница только в том, что в M какой-то индекс есть всегда, а в РСУБД он может быть, а может и нет.
При этом пользователю М, в зависимости от наличия или отсутствия индекса, придётся туго - либо писать недостающий код, либо нервно курить в сторонке. Он просто не сможет получить эти данные. А пользователь РСУБД в любом случае получит свои данные - только в одном случае значительно быстрее.
Можно этим вообще голову не забивать, а попросить СУБД - она сама построит требуемые индексы.
Даже если не просить, то в многих случаях оптимизатор может дать указание построить временный индекс для конкретного запроса.
Убедительно прощу не отвечать на этот пост, а прочитать весь топик сначала. Надоело по кругу ходить. Детсад блин.
Мы тут прекрасно понимаем для чего могут использоваться М-системы и где они будут очень хороши.
Осталось другим понять, что этим классом задач весь мир не ограничен.
20 ноя 06, 14:02    [3424347]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
ну я
3. Не в алфавитном порядке, а в индексной сортировке, в порядке, определенном collation. Алфавитный - это частный случай, причем далеко не по умолчанию.
Да я и не утверждаю. В доке написано, что $ORDER(variable) returns the name of the next defined local variable in alphabetic collating sequence. Никаких уточнений нет.

Кстати, намек: между двумя обращениями к $o могут пройти вставки данных из других процессов, так что выдача будет не обязательно всех подряд, а только тех, кто были следующими на момент обращения.
Это кому намёк?
IMHO это к вопросу об ACID и изоляции транзакций :-)
20 ноя 06, 14:12    [3424414]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ptn
Даже две строки на М - будут на порядок быстрее того что вы написали :)
 new rate quit:$o(^Tarif(ID,[некоторая]+1),-1,rate)'="" rate 
 quit 0

Тут всего два "атамарных" оператора поиск и возврат. Две P-команды для байт машины. Никаких сортировок, никаких переборов.

Гы... атамарных...
Что-то в физику потянуло - байт машина первого рода :-)
Может это вообще за одну процессорную инструкцию выполняется, а данные материализуются из эфира?
Пойду выпью йаду...
20 ноя 06, 14:20    [3424457]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

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

Даже две строки на М - будут на порядок быстрее того что вы написали :)

Во-первых, не факт(агрументов я не увидел, хотя я к этому уже привык:), а во-вторых выборка одной строки из одной таблицы занимает мало времени и мало кому интересна
Ptn

 new rate quit:$o(^Tarif(ID,[некоторая]+1),-1,rate)'="" rate 
 quit 0
Тут всего два "атамарных" оператора поиск и возврат. Две P-команды для байт машины. Никаких сортировок, никаких переборов.

А как же +1 и сравнение ="" ? Т.е. уже как минимум 4 :)
Ptn
Посмотри план своего запроса - оцени время для его выполнения.

Посмотрим вместе(ничего что другая таблица?):
select top 1 * from r_struct where fldid<100 order by fldid desc

|--Top(1)
|--Clustered Index Seek(OBJECT:([pif06_test].[dbo].[r_struct].[PK_r_struct]), SEEK:([r_struct].[fldid] < 100) ORDERED BACKWARD)
Тоже однако никаких сортировок, никаких переборов. Откуда будет разница на порядок?
Ptn

PS: На логическом уровне ничья :) - с той лишь разницей что если мне будет лениво я точно также могу написать
select top 1 * from Tarif where date <=[некоторая] order by date desc
И план запроса можно посмотреть? Что б на ничью-то
20 ноя 06, 15:10    [3424809]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
[quot pavelvp]В доке написано, что $ORDER(variable) returns the name of the next defined local variable in alphabetic collating sequence. Никаких уточнений нет.[quot]
))))
Это если передается имя неиндексированной локальной переменной, то возвращает имя другой локальной переменной, и в алфавитном порядке. Опять же расширение Интерсистемс. По стандарту $order работает только с индексами.

Представляю, какая может быть каша в голове ))))
20 ноя 06, 15:11    [3424818]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
pavelvp
Ты знаешь, мы тут не такие тупые как тебе кажется. Совершенно естесственно, если в таблице из двух полей первое поля является ключом, было бы неплохо если бы по этому полю был построен индекс.

Жаль что Вы так воспринимаете. (Про тупых).

Так же естественно что условия по хорошему нужно оговоривать.

Так же неестественно - что пример Сергея сравнили с таблицей из ДВУХ полей. Разговор плясал от этого.
В этом случае даже если учесть естественный ключ - то это привет нас именно на ту ситуацию где 1,2,3 не одно и то же что и "1,2,3"

Потому что тут IMXO нужна таблица с 4-мя полями! Это понятно ? С соотвествующими ДОП индексами.


Это также естесвенно как и для эффективного поиска в структуре
^a(1)="Иванов"
^a(2)="Петров"
^a(3)="Сидоров"
Сидорова , эти данные нужно добавить в индекс.


Вы знаете я тоже не даун :) Структуру она как бы вперед рождается.


Разница только в том, что в M какой-то индекс есть всегда, а в РСУБД он может быть, а может и нет.

На уровне хранения он таки есть и в РСУБД но это неважно


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


только если это необходимо - в 80% случаях я пишу
/// индекс по Адресу
Index I1 On Address;
и иду в сторонку пить кофе .

>>Можно этим вообще голову не забивать, а попросить СУБД - она сама построит требуемые индексы.

Например так же как я сделал это выше ? :)

PS: читал . поинт.
20 ноя 06, 15:42    [3425145]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
ну я
Опять же расширение Интерсистемс. По стандарту $order работает только с индексами.

Представляю, какая может быть каша в голове ))))
А, блин, наворотили. Невнимательно читаю. Думаю можно простить :-)
Тогда вопросик, а то я не понял:
^a("1,1,2");
^a("1,2,3");
^a("1,2,4");
Что в этом случае вернёт $order("1,2,")?
Она вообще вернёт что-то, или обязательно в индексе должен присутствовать ключ "1,2,"?
20 ноя 06, 15:43    [3425159]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Croaton
Member

Откуда:
Сообщений: 11
pavelvp
ну я
Опять же расширение Интерсистемс. По стандарту $order работает только с индексами.

Представляю, какая может быть каша в голове ))))
А, блин, наворотили. Невнимательно читаю. Думаю можно простить :-)
Тогда вопросик, а то я не понял:
^a("1,1,2");
^a("1,2,3");
^a("1,2,4");
Что в этом случае вернёт $order("1,2,")?
Она вообще вернёт что-то, или обязательно в индексе должен присутствовать ключ "1,2,"?


>w $o(^a("1,2,"))
>1,2,3
20 ноя 06, 15:54    [3425252]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
SergSuper
А как же +1 и сравнение ="" ? Т.е. уже как минимум 4 :)

Ptn
Посмотри план своего запроса - оцени время для его выполнения.

Посмотрим вместе(ничего что другая таблица?):
select top 1 * from r_struct where fldid<100 order by fldid desc

|--Top(1)
|--Clustered Index Seek(OBJECT:([pif06_test].[dbo].[r_struct].[PK_r_struct]), SEEK:([r_struct].[fldid] < 100) ORDERED BACKWARD)
Тоже однако никаких сортировок, никаких переборов. Откуда будет разница на порядок?
Ptn

PS: На логическом уровне ничья :) - с той лишь разницей что если мне будет лениво я точно также могу написать
select top 1 * from Tarif where date <=[некоторая] order by date desc
И план запроса можно посмотреть? Что б на ничью-то


+ и = , поставь у себя в запросе fldid<=100 а я уберу + :)

= считать хотите - ну что ж тогда давайте приплюсуем всё остальное.

1. Разбор запроса - проверка его на синтаксис
2. Построение плана
3. Инициализация переменных
4. Выполнение плана
5. Выдача результатов плана ( его в плане нет - но смею Вас увери '=' там будет предостаточно)

Конечно же 1 и 2 будут актуальны для динамических запросов.

Операций аналогичных выполнению плану - там ровно одна - $order - если вы не верите что выполнение $order быстрее чем Выполнение одного шага ПЛАНА - то, увы, я вас ничем убедить не смогу.

>>Тоже однако никаких сортировок, никаких переборов.
Ой ляпота :) класстерный индекс - да и Seek и Seek и еще и задом наперед - а что жэ это тогда если не позиционирование (по сортированному индексу) и перебор (или перебор одного значения это уже не перебор)

План
select top 1 * from Norms.PNormGrid Where Norm=1 and ToDateB<=CURRENT_DATE order by ToDateB desc  
 
Query Plan Relative cost = 2238 

Read index map Norms.PNormGrid.I1, using the given Norm, and looping on ToDateB (with a range condition) and ID.

For each row:

 Read master map Norms.PNormGrid.cID, using the given idkey value. 
 Output the row.  

То что план в Cach'e может вычисляться меннее эффективто я не спорил.

Но то что "машина" по выполнению плана - может быть быстрее байт-машины при равных условиях верится с трудом
20 ноя 06, 16:07    [3425349]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ptn
Потому что тут IMXO нужна таблица с 4-мя полями! Это понятно ? С соотвествующими ДОП индексами.
??? В М эта структура ложится в один глобал. Соответственно в РСУБД индекс будет тоже один. Если ты извини, как баран, упёрся и не желаешь думать, то пусть будет 4 атрибута или скажем 200. Ну так, на всякий случай. Место они занимать не будут. Но эквивалентный индекс будет всё равно один!!!
20 ноя 06, 16:10    [3425374]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ptn
Ой ляпота :) класстерный индекс - да и Seek и Seek и еще и задом наперед - а что жэ это тогда если не позиционирование (по сортированному индексу) и перебор (или перебор одного значения это уже не перебор)
ЖЖЖЖ...
Ну расскажи, как же у нас вот эта штука $o(^Tarif(ID,[некоторая]+1),-1,rate) работает.
Давай, колись.
Фразу "а внутри у ней неонка" можно пропустить. Давай, жги!
20 ноя 06, 16:21    [3425479]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Забыл добавит что для моего примера не нужен индекс - не кластерный ни какой либо другой.

Соовтественно нет и накладных расходов связанных с его поддержанием в актуальном состоянии.

>> то пусть будет 4 атрибута или скажем 200

индекс в 4-атрибута у таблицы в 2-а ? Мысль поясни о Великий.

order выполнять байт машина - обратитесь в интерситемс за подробностями
20 ноя 06, 16:26    [3425519]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
order выполнять байт машина - обратитесь в интерситемс за подробностями


2 pavelvp, ты ЗНАЛ о ВЕЛИКИЙ !!!
Внутре у ей НЕОНКА
20 ноя 06, 16:29    [3425533]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
И читай внимательнее

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

А почему тогда не по 3-м или по 2-м ?

ЗЫ: :down:
20 ноя 06, 16:32    [3425562]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Ptn
И читай внимательнее

ДОП индексы упомяны затем, что Вы запели про Ваш "естесвенный" индекс который же конечно же все подразумевают, но ОН не будет сразу "естествено" по 4-м полям.
Потому что 4 поля в общем случае не нужны. Достаточно одного :-)

PS
2 Ptn Перестаньте сюда писать. Над вами наверное кот Экслера уже ржот...
Чтобы узнать как работает $order посмотрите на план запроса SergSuper. Не буквально конечно, но плюс минус... представление получить можно.
Хотя нет. Всё-таки обратитесь к разработчикам. Только не забудьте узнать какую напругу на неонку подавать. А то, бац! И сгорит на втором байте...
20 ноя 06, 16:51    [3425718]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
OS/360
Guest
Ptn

Но то что "машина" по выполнению плана - может быть быстрее байт-машины при равных условиях верится с трудом


а чем они отличаются???
20 ноя 06, 17:35    [3426012]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67390
Блог
OS/360
а чем они отличаются???

"Чем армян".
20 ноя 06, 18:20    [3426304]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
OS/360
Guest
softwarer
OS/360
а чем они отличаются???

"Чем армян".


Я ж почти серьёзно - два интерпретатора . (Не рассматриваю вариант компиляции ESQL в машинный код)
20 ноя 06, 18:39    [3426408]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
OS/360
Guest
2 softwarer:
Откуда следует, что интерпретатор байт-кода M эффективнее интерпретатора (или компилятора) в SQL СУБД?
20 ноя 06, 18:41    [3426422]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67390
Блог
OS/360
Я ж почти серьёзно

Вы имхо не тому собеседнику серьезные вопросы задаете.

- Ну чем, чем интерпретатор байт-кода М эффективнее?
- Чем в SQL СУБД

(c)
20 ноя 06, 19:47    [3426628]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Ptn

Операций аналогичных выполнению плану - там ровно одна - $order - если вы не верите что выполнение $order быстрее чем Выполнение одного шага ПЛАНА - то, увы, я вас ничем убедить не смогу.

Сильно. Глубоко копает однако.


Sergei Obrastsov
c127

Это не хеш, это пример того, как делаются ошибки, когда доходит до "все напишем ручками".

Это пример, что докопаться можно даже то телеграфного столба. Продолжайте в том же духе, ага.

Еще раз повторяю, то, что Вы предлагаете не хеш абсолютно. У Вас обычный индекс, использующий встроенный алгоритм поиска М системы, если в М, например, полный перебор, то и Ваш так называемый "хеш" ^index(hash_x1)=number будет полным перебором, хотя в теории должен быть константой. При желании конечно назвать хешем можно и это, достаточно назвать переменную hash_x1, чтобы неизвестно какой алогоритм стал хешем. А назвали бы btree_x1, был бы бинарным деревом.

Прежде чем что-то дописывать руками подучили бы все-таки матчасть.


Sergei Obrastsov

^index(hash_x1, number_1)
^index(hash_x1, number_2)
...
Не сложно было догадаться, правда ведь?

Тут догадаемся, это несложно, там руками допишем. Легко и приятно работать с М системами.

А почему я должен догадываться, Вы привели пример реализации хеша-таблицы на основе деревьев. Даже этот элементарный пример с ошибками, в промышленных системах ошибок будет больше. Тему о том, что в М системе что-то там допишем руками, можно смело закрывать, совершенно ясно чем закончится такое дописывание.
21 ноя 06, 01:44    [3427282]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 37 38 39 40 41 [42] 43 44 45 46 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить