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

Откуда: Красноярск
Сообщений: 317
Gluk (Kazan)
Rus000
FULLSCAN никогда не буде быстрее поиска по дереву. Попытаетесь доказать обратное?


Вот тут Вы не правы. Поиск по индексу - дополнительные издержки и существует масса случаев когда эти издержки не окупаются. Например когда табличка помещается в одном блоке. Или когда из таблички нужны ВСЕ данные. Будете спорить ?


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

Про ВСЕ записи здесь не очень к месту - мы ведь рассматривали скорость извлечения данных а не их полноту
16 ноя 06, 14:09    [3409277]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

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

Gluk (Kazan)
+1
З.Ы Добавлю, что FULL SCAN будет легче по затратам и быстрее, если индекс, по которому идет отбор, яляется монотонным.


мммм... не могли бы Вы дать определение монотонного индекса, что-то я такого не встречал в литературе
16 ноя 06, 14:12    [3409305]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
мод
Зл0й
Скорее на "IMS для бедных", со сломанным IMS/TM и вообще кастрированный.

Не, не трогайте IMS :). М и рядом не стояло.


итересно получается M-системы пинают, а ИМС нельзя?

Кстати, может быт Вам известны масштабные внедрения этой субд? Она вообще-то жива еще?
16 ноя 06, 14:14    [3409329]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
мод
Rus000
может потрудитесь дать формальные определения этих терминов и все успокоятся?

См. учебники по программированию и БД. И не надо успокаиваться, надо дерзать :)


Проше конечно послать, чем указать источник или само определение ... тогда не используйте в своих аргументах ссылки на определения или приведите их всем, чтобы было понятно кто прав а кто нет. Это же не сложно, правда ведь. А книжки листать конечно можно, но слишком мало времени в сутках для этого.
16 ноя 06, 14:17    [3409354]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Rus000
[quot Gluk (Kazan)]Однако формально Вы правы.


Не только формально, это один из топов в факах по Oracle
вопрос: "Почему Oracle не использует индекс"
16 ноя 06, 14:28    [3409440]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Rus000
Согласен, если кортежи помещаются в одном дисковом блоке, но имхо это вырожденный случай


Не совсем так. Если оптимизатор решит, что таблицу выгодно всегда держать в буферном кэше. Это существенно больший размер таблиц чем просто один блок. И если читается более 20% (если склероз не попутал) данных из таблицы
16 ноя 06, 14:31    [3409477]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
Sergei Obrastsov

создание индексно-последовательного файла VAR:
set VAR('A')=1
set VAR('A','B')=2
set VAR('A','B','C')=3
set VAR('B')=4
set VAR('B','C')=5
16 ноя 06, 15:03    [3409808]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
мод
Guest
Rus000

Кстати, может быт Вам известны масштабные внедрения этой субд? Она вообще-то жива еще?

Судя по тому, что иногда требуются спецы по ней, еще живет на ихних mainframe.
16 ноя 06, 15:12    [3409894]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
pavelvp
Каким образом это сделает M-система?

В каких условиях? Я еще раз подчеркну, что я предлагал полноценно-индексированное для
данной задачи дерево, где эта ситуация, естественно, учитывается. Оппонент же просто слил все индексы в одну кучу, не задумываясь о производительности. Full Scan, конечно, рулит, но не для
сотен миллионов же записей.


Да, блин, надоело... Что Вы извиваетесь как уж на сковороде?!
Какие, нафиг, условия??? Что где учитвается???
Или Вы читать и понимать русский язык разучились?
Вот Ваш опус про fullscan:

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? Обратите внимание на сортировку.


Я спрашиваю - как это сделает M-система?
Вот этих конкретных, описанных Вами, условиях...

Ваш ответ:
Sergei Obrastsov
В каких условиях?

Вы сами привели такой пример. Какие ещё Вам нужны условия??? Или мне их нужно выдумать???
Я еще раз подчеркну, что я предлагал полноценно-индексированное для
данной задачи дерево, где эта ситуация, естественно, учитывается. Оппонент же просто слил все индексы в одну кучу, не задумываясь о производительности. Full Scan, конечно, рулит, но не для
сотен миллионов же записей.


Вот мой ответ на Ваш самый первый пример:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=27#3383864

Вот Ваш предыдущий пример:
^dft(date)=count
^dft(date,"idx",idx)=v1~v2~v3~v4~v5~v6~v7...v18
^dft(date,"tr",v1)=count
^dft(date,"tr",v1,idx)=
^dft(date,"cat",v2)=count
^dft(date,"cat",v2,idx)=
^dft(date,"pa",v3)=count
^dft(date,"pa",v3,v4)=count
^dft(date,"pa",v3,v4,idx)=
^dft(date,"pb",v4)=count
^dft(date,"pb",v4,v3)=count
^dft(date,"pb",v4,v3,idx)=
^dft(date,"ti",v5)=count
^dft(date,"ti",v5,idx)=
^dft(date,"to",v6)=count
^dft(date,"to",v6,idx)=
^dft(date,"ma",v15)=count
^dft(date,"ma",v15,v16)=count
^dft(date,"ma",v15,v16,idx)=
^dft(date,"mb",v17)=count
^dft(date,"mb",v17,v18)=count
^dft(date,"mb",v17,v18,idx)=

Вот вам ответил SergSuper:
SergSuper

insert dft (id, attr)
  select @date+"/"+"pb"+@v4+"/"+@v3+"/"+@idx, "Вася"

Вы не понимаете, что эти две структуры идентичны?
16 ноя 06, 16:26    [3410504]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

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

Кстати, может быт Вам известны масштабные внедрения этой субд? Она вообще-то жива еще?

Судя по тому, что иногда требуются спецы по ней, еще живет на ихних mainframe.

У... IMS живее всех живых. Живёт и развивается http://www-306.ibm.com/software/data/ims/.
Вот 10-ая версия выходит.
По поводу масштабных внедрений думаю, что процентов 70% финансовых транзакций в мире проходит через IMS. IMHO.
16 ноя 06, 16:33    [3410559]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Rus000

Про ВСЕ записи здесь не очень к месту - мы ведь рассматривали скорость извлечения данных а не их полноту

Отчего ж не очень к месту? При извлечении ВСЕХ данных, полное сканирование таблицы таки будет быстрее, чем извлечение этих данных с использованием индекса.
Собственно, это предельный случай, однако ситуация ровно та же и в случае, если кардинальность индекса невелика. Просто потому, что когда говорят "там логарифм, а тут линейно" слишком упрощают: всё же, это лишь оценки типа О-большое, O(n) для полного сканирования и O(ln(n)) для выборки по индексу (вообще говоря, O(log_k(n)). Не слишком строго, однако наглядно можно оценить время выборки t как зависимость
t1=C1*n, для полного скана
t2=C2*ln(n), для извлечения по ключу
Причём С2 очевидно больше, ввиду бОльших накладных расходов.
16 ноя 06, 16:50    [3410700]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

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

Это действительно очевидно. Как и то, что выборка элементов 2-го и последующих уровней,
без задания 1-го, пойдет как Full Scan. Я не слишком самоуверен? :)


Слишком. 2 уровень НИЧЕМ не отличается от первого. Если в первом не было FullScan с какого перепуга он будет во втором ???

Теперь самоуверены Вы. :)
Поясняю. Скажем, индексы выглядят следующим образом:
^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? Обратите внимание на сортировку.


Отвечаем. Элементарно. Если конечно у Вас не М или Каше, а нормальный SQL сервер.
Используем мою же таблицу из двух полей, но добавляем еще вычисляемое поле.Для простоты индексируем 2-й уровень, но аналогично можно и любой другой. Решетка в имени таблицы означает что она временная, что ни на чем больше не отражается

create table #dft(
id varchar(999),
attr varchar(999),
level2 as case when patindex('%/%',id)=0 then '' else substring(id, patindex('%/%',id)+1,900) end
)
До этого момента мы имеем всё равно полный аналог Каше.
А вот теперь делаем индекс по вычисляемому полю и приобретаем то, чего в Каше нет
create index ddd on #dft(level2)
заполняем приведёнными данными
insert #dft
select '25081565/34744','qxQ'
union select '25081565/79658','5Me'
union select '25081565/9148513041','pQ'
union select '25081567/76909','qyZ'
union select '25081567/9148502606','283'
union select '25081567/9148502606','x5f'
union select '25081570/73798','lTr'
union select '25081571/53189','bFt'
union select '25081571/75270','c1I'
union select '25081571/75270','c1W'
union select '25081571/75270','c6Q'
union select '25081575/9148502606','qf'

и наконец сам запрос
select * from #dft where level2='9148502606'
и его план:
  |--Compute Scalar(DEFINE:([#dft].[level2]=If (patindex('%/%', [#dft].[id])=Convert(0)) then Convert('') else substring([#dft].[id], patindex('%/%', [#dft].[id])+1, 900)))
|--Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([tempdb].[dbo].[#dft]))
|--Index Seek(OBJECT:([tempdb].[dbo].[#dft].[ddd]), SEEK:([#dft].[level2]='9148502606') ORDERED FORWARD)
Поиск по индексу, никакого фуллскана.
И еще сам оптимизатор будет решать как ему лучше выбирать - по индексу или фуллсканом, и еще много чего поимеем, несмотря на то что мы выбрали далеко не самую оптимальную структуру (если теперь забросите М и перейдёте на SQL - не надо её применять )
16 ноя 06, 18:03    [3411360]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

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

Про ВСЕ записи здесь не очень к месту - мы ведь рассматривали скорость извлечения данных а не их полноту

Отчего ж не очень к месту? При извлечении ВСЕХ данных, полное сканирование таблицы таки будет быстрее, чем извлечение этих данных с использованием индекса.
Собственно, это предельный случай, однако ситуация ровно та же и в случае, если кардинальность индекса невелика. Просто потому, что когда говорят "там логарифм, а тут линейно" слишком упрощают: всё же, это лишь оценки типа О-большое, O(n) для полного сканирования и O(ln(n)) для выборки по индексу (вообще говоря, O(log_k(n)). Не слишком строго, однако наглядно можно оценить время выборки t как зависимость
t1=C1*n, для полного скана
t2=C2*ln(n), для извлечения по ключу
Причём С2 очевидно больше, ввиду бОльших накладных расходов.


Да, но речь шла о скорости вообще говоря выборки произвольного объема а не только полной, которая является крайним случаем.

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

Однако это n все же считаю вырожденным случаем для боле-менее серьезных массивов данных, поэтому на практике может не рассматриваться. Формально - да, конечно.
16 ноя 06, 19:53    [3411899]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

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

Да, но речь шла о скорости вообще говоря выборки произвольного объема а не только полной, которая является крайним случаем.

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

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


Вы просто хранилищами данных не занимались никогда. У меня в хранилище данных таких "вырожденных случаев которые на практике можно не рассматривать" полным-полно. В аналитической работее вообще такие "вырожденные случаи" как "просмотреть весь набор данных и сосчитать по нему некую статистику" скорее правило чем исключение.
16 ноя 06, 20:40    [3412041]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

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

Gluk (Kazan)
+1
З.Ы Добавлю, что FULL SCAN будет легче по затратам и быстрее, если индекс, по которому идет отбор, яляется монотонным.


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


Строго говоря если селективность индекса (кардинальность атрибута) низкая, то Full Scan такой таблицы работает быстрее чем выборка по b-tree индексу. Померить "напряжометром" в Оракле несложно - нужно создать IOT (Index Organized Table) и обычную (Heap Organized) таблицу одинаковой структуры и погонять запросы. В случае IOT данные как раз лежат в столь любимом многими дереве, а в случае обычной таблицы - в куче. Интуиция мне подсказывает что для случая совсем низкой селективности лучше всего работает Full Scan на heap-organized table, при селективности чуть повыше будет лучше работать опять-таки обычная таблица с bitmap индексом, а когда селективность станет достаточно высокой - будет иметь смысл IOT или B-tree индекс.
16 ноя 06, 20:50    [3412057]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ЛП
Guest
2 Rus000
Да, но речь шла о скорости вообще говоря выборки произвольного объема а не только полной, которая является крайним случаем.

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

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

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

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

Вам уже русским по белому цифры озвучили - товарисч Глюк Казанский утверждает, что индекс вполне может не использоваться, если селективность условия по индексу такова, что в итоге выбирается больше 20% данных из таблицы.
А у меня в памяти так вообще обрывки воспоминаний с пятипроцентным барьером селективности, возможно для ранних версий оракула.

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

--------

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

Дерево акбар, и логарифм пророк его.
16 ноя 06, 20:55    [3412069]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SergSuper
Для простоты индексируем 2-й уровень, но аналогично можно и любой другой.

Все понятно, можно уже не продолжать. Временный индекс на сотнях миллионов записей - очень
удобная штука, юзер будет счастлив ждать создания. Кстати, создание индекса - это
ведь Full Scan, так нафига заморачиваться? И в завершение, а разве мы говорили про какие-то
дополнительно создаваемые индексы?
16 ноя 06, 22:59    [3412285]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
OS/360
Guest
Sergei Obrastsov

Все понятно, можно уже не продолжать. Временный индекс на сотнях миллионов записей - очень
удобная штука, юзер будет счастлив ждать создания. Кстати, создание индекса - это
ведь Full Scan, так нафига заморачиваться? И в завершение, а разве мы говорили про какие-то
дополнительно создаваемые индексы?


Алло , гараж? Где временный индекс? Читаем по губам
автор
Решетка в имени таблицы означает что она временная, что ни на чем больше не отражается
[/quot]

Для задних рядов: примеры для MS SQL на данном сайте принято оформлять с использованием временных таблиц дабы не засирать базы.

P.S. А в Каше можно осоздать временный объект с автоматическим уничтожением?
16 ноя 06, 23:13    [3412314]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
OS/360
Алло , гараж? Где временный индекс? Читаем по губам
автор
Решетка в имени таблицы означает что она временная, что ни на чем больше не отражается

Ах, он постоянный? А с какого перепугу? Меня уверили, что таблица адекватна. Значит никаких
больше полей и индексов.

OS/360

P.S. А в Каше можно осоздать временный объект с автоматическим уничтожением?

Теперь да.
16 ноя 06, 23:20    [3412322]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

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

Вот вам ответил SergSuper:
SergSuper

insert dft (id, attr)
  select @date+"/"+"pb"+@v4+"/"+@v3+"/"+@idx, "Вася"

Вы не понимаете, что эти две структуры идентичны?

Нет, не понимаю. Видимо, это новое веяние в РБД - использовать объединенный индекс, чтобы не заморачиваться на отдельные. Впрочем, Full Scan рулит, конечно.
16 ноя 06, 23:34    [3412342]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Sergei Obrastsov

Ах, он постоянный? А с какого перепугу? Меня уверили, что таблица адекватна. Значит никаких
больше полей и индексов.

К сожалению, вы так и не расслышали, что при проектировании баз РСУБД, индексы не рассматриваются как объекты логического уровня. По той простой причине, что на логику работы они не влияют, один и тот же запрос что с индексом, что без индекса, одно и то же вернёт, вопрос лишь в скорости.
17 ноя 06, 00:07    [3412385]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

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

Ах, он постоянный? А с какого перепугу? Меня уверили, что таблица адекватна. Значит никаких
больше полей и индексов.

К сожалению, вы так и не расслышали, что при проектировании баз РСУБД, индексы не рассматриваются как объекты логического уровня. По той простой причине, что на логику работы они не влияют, один и тот же запрос что с индексом, что без индекса, одно и то же вернёт, вопрос лишь в скорости.

А я и не спорю. Только о таком подходе нужно предупреждать заранее. Дескать "я гарантирую
адекватность таблицы с двумя полями любому дереву, с учетом моего права добавлять любые
индексы как мне захочется". Не правда ли, есть разница?
17 ноя 06, 00:43    [3412423]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

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

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

Право добавлять индексы в РСУБД вообще-то подразумевается, как нечто само собой разумеющеся. Вообще, в оракле таблица может лежать в виде дерева, индекс там не нужен. В Oracle я могу "таблицу" реализовать в виде: кучи, B-tree дерева, хэш -таблицы. Причем реализация на низком уровне уже сделана толковыми ребятами из Оракла, от меня требуется что-то типа "CREATE TABLE ... ORGANIZATION INDEX;". У каждого варианта есть свои плюсы и минусы, и соответствующая облать применения. В других реляционных СУБД есть и другие физические реализации таблиц, например индекс-последовательные файлы. А теперь скажите откровенно, вы сможете оргарнизовать в Каше например хэш-таблицу и обеспечить согласованное чтение из нее одновременно с ее изменением?
17 ноя 06, 01:21    [3412474]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
ЛП
А у меня в памяти так вообще обрывки воспоминаний с пятипроцентным барьером селективности, возможно для ранних версий оракула.

Вообще говоря, эта цифра плавающая. Вокруг http://www.amazon.com/phrase/index-cost-adj-parameter гремели целые битвы, если коротко, это параметр, настраивающий относительную привлекательность того и другого метода доступа.
17 ноя 06, 01:42    [3412488]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Зл0й
А теперь скажите откровенно, вы сможете оргарнизовать в Каше например хэш-таблицу и обеспечить согласованное чтение из нее одновременно с ее изменением?

В Cache структура одна - дерево. Можно ли на ее основе сделать hash-таблицу, bitmap-карту
или что-то еще? Можно. Но это будет уже внешняя организация данных над внутренней структурой. А в чем проблема с согласованным чтением? Или Вы просто забываете, что пользователи не имеют доступа на нижний уровень и работают ТОЛЬКО через предложенный им интерфейс?
17 ноя 06, 01:52    [3412494]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 32 33 34 35 36 [37] 38 39 40 41 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить