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


Как попросишь, столько и отсканирует. Кстати, если эта 1000 равномерно размазана по таблице, Full Scan может быть эффективнее доступа по индексу


неужели?

количество просмотренных блоков при fullscan = n а для сбалансированного дерева = log_k(n)

Чувствуете разницу?

FULLSCAN никогда не буде быстрее поиска по дереву. Попытаетесь доказать обратное?

А что там доказывать, на самом деле оценка сложности fullscan=n+F, дерева=log_k(n)+D, где F,D - константы, не зависящие от n. При каком-то соотношении F,D,n может оказаться, что fullscan будет быстрее. Подсказываю, в РСУБД fullscan обычно быстрее при n меньше 10-15. Можно посмотреть планы и убедиться, что при малых n оптимизатор выбирает fullscan. Тут даже был целый топик, там кто-то из ООСУБД-шников завел МССКЛ-евскую таблицу в пять записей, смотрел план запросов, видел fullscan и на этом основании пытался доказать, что РСУБД всегда сканируют таблицу.

Но это уже и без меня сказали.


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

В Cache структура одна - дерево. Можно ли на ее основе сделать hash-таблицу, bitmap-карту
или что-то еще? Можно.


А ну-ка покажите если не сложно как на основе дерева создается хеш таблица.
17 ноя 06, 02:40    [3412534]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

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

В Cache структура одна - дерево. Можно ли на ее основе сделать hash-таблицу, bitmap-карту
или что-то еще? Можно.


А ну-ка покажите если не сложно как на основе дерева создается хеш таблица.

Без проблем.
Вариант 1, самый простой - используем полученные hash-значения вместо индексов.
^data(number)=x1
^index(hash_x1)=number
Минус - разницы с обычным индексом никакой. Выигрыш возможен за счет уменьшения размера индекса и/или обхода принудительной сортировки индексов.

Вариант 2, усложненный - составление строки из hash-значений.
^data(1)=x1
^data(2)=x2
^data(3)=x3

str=~hash_x1~hash_x2~hash_x3...
^DataHash=str

Минус - строка ограничена 32K. Вариант - хранение нескольких строк. Выигрыш - скорость
поиска.
^DataHash(1)=str1
^DataHash(2)=str2
...

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

Это все навскидку. По некоторому размышлению, наверно можно найти еще другие способы.
17 ноя 06, 04:18    [3412542]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

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

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

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

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


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


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

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

Вы акцент делаете немного на другом и здесь я не выжу предмета спора - да требуется, да в DWH есть такие случаи, но сейчас не об этом
17 ноя 06, 06:33    [3412592]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

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

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


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


Строго говоря если селективность индекса (кардинальность атрибута) низкая, то Full Scan такой таблицы работает быстрее чем выборка по b-tree индексу.


Есть т.н. плотные индексы, есть разреженные. В случае селективности атрибута большей s>k>1 (где s-селективность текущего атрибута, k-пороговое значение), все равно разреженный индекс эффективней в силу физической природы своего построения - он просто имеет меньше дисковых блоков которые могут соответственно быстрее прочитаны контроллером.

Однако есть некоторое пороговое значение k для селективности, ниже которого, действительно, фуллскан будет быстрее хотя бы в сиду того, что файл данных может лежать в последовательно расположенных блоках, а рбота через разреженный индекс(который может лежать на диске в "стороне" от файла данных) влечет обращения сначала к блокам указателей и только потом к блокам данных. Вопрос в том чему равен порог k? Имхо k=2*m, где m=(размер блока/размер записи)

Т.е. если в дисковом блоке помещается m записей то блок указателя должен адресовать как минимум 2 блока данных , т.е. 2*m , чтобы быть эффективным ... соответсвенно селективность атрибута должна быть выше этого значения для того чтобы индекс был более эффетивен
17 ноя 06, 06:47    [3412603]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
ЛП
2 Rus000
Да, но речь шла о скорости вообще говоря выборки произвольного объема а не только полной, которая является крайним случаем.

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


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

ЛП

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


как говорится "и вы утверждайте". Что с того что Gluk утверждает? Можно по это подвести некоторые математические/физические оценки? На худой конец ссылку на источник такой цифры.
Вламываетесь в интиллигентный спор, сслаетесь на слова других оппонентов, у вас-то что есть?

ЛП

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


во-первых, никто и не утверждал что дерево всегда эффективно. однако для операции поиска по ключу - это самая эффективная структура и доказательство тому хотя бы b-treee организация физической стратегии хранения данных в СУБД, в том числе и РСУБД.

Кроме того, никто не оспаривал того факта что логическая (концептуальная) схема данных может быть эквивалентно выражена как таблицами, так и деревьями. Панацеи к сожалению нет. Пока.
17 ноя 06, 07:01    [3412617]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
c127
А что там доказывать, на самом деле оценка сложности fullscan=n+F, дерева=log_k(n)+D, где F,D - константы, не зависящие от n. При каком-то соотношении F,D,n может оказаться, что fullscan будет быстрее.


Думаю правильнее fullscan=n*F, дерева=log_k(n)*D, где F,D - константы. Это следует из определения O(fn())

Я уже согласился выше, с тем, что при определенных n, размере блока, размере записи фуллскан будет эффективнее индексного поиска
17 ноя 06, 07:36    [3412652]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Rus000
хамство - признак тупости

Устами младенца.... Жаль только, истину еще надо уметь правильно применить.

Rus000
Можно по это подвести некоторые математические/физические оценки?

Можно. Они даже были названы в топике, равно как и ключевые слова для поиска более подробных оценок в гугле.

Rus000
однако для операции поиска по ключу - это самая эффективная структура

17 ноя 06, 07:41    [3412658]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

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


Вот статья, которую очень рекомендую почитать при наличии свободного времени и желания. После прочтения, думаю станет ясно, что нельзя игнорировать подобные "частные" случаи и говорить лишь о "формальной" правоте. Речь идет о СУГУБО практических вещах:

Доступ по индексу ДАЛЕКО НЕ ВСЕГДА оптимальнее полного просмотра
17 ноя 06, 08:32    [3412731]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
А в чем проблема с согласованным чтением? Или Вы просто забываете, что пользователи не имеют доступа на нижний уровень и работают ТОЛЬКО через предложенный им интерфейс?


Проблема согласованного доступа отнюдь не ограничивается предоставлением доступа исключительно через разработанный интерфейс. Тема для поиска: Уровни изоляции транзакций. Советую ознакомиться.

Собственно мы подошли к самому интересному: Как в Cache или M реализуется ACID ???

P.S. Что касается пресловутой "гибкости" типа "что хочу то и ворочу" (хоть хеш-таблицы, хоть BITMAP-индексы, и все на глобалях), то это ведет:
1. К отсутствию стандартных решений
2. К обилию наколеночных поделок
3. К игнорированию разннобразных нетривиальных эффектов (по ACID в частности) авторами наколенок
4. К введению дополнительного ЛОГИЧЕСКОГО уровня (внизу все то-же B-дерево) - проблемы производительности наколенок
17 ноя 06, 08:49    [3412771]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

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

Истерики не было, с чего вы взяли :) Я спросил как в Cache реализуется ACID ?
Вопрос задавался неоднократно и не только мной. Будем продолжать игнорировать ???
17 ноя 06, 09:54    [3413088]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Кстати, заодно не подскажите, почему кашисты так дружно не рекомендуют использование SQL-расширения. Не потому ли, что оно и близко не показывает той производительности и функциональности, что присутствует у столь ругаемых ими РСУБД ?

Это и предыдущее сообщение ответ на
17 ноя 06, 10:03    [3413138]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Gluk (Kazan)
Кстати, заодно не подскажите, почему кашисты так дружно не рекомендуют использование SQL-расширения. Не потому ли, что оно и близко не показывает той производительности и функциональности, что присутствует у столь ругаемых ими РСУБД ?

Видимо потому, что это эмуляция. Мне вот поначалу казалось, что по сравнению с основными
РСУБД будет выигрыш по производительности, ан нет, далеко не всегда.
Что же касается "столь ругаемых ими", то это обычное преувеличение. Я ничего не имею против ни SQL, ни РСУБД. Я против фанатичных утверждений типа "РСУБД есть высшая степень творения и ничего нет лучше, быстрее и удобнее!!!". Поживем - увидим.
17 ноя 06, 10:25    [3413296]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

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

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

Чего-то я уже начинаю сомневаться в Вашей ... адекватности. Последний раз объясняю.

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

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

Что касается а разве мы говорили про какие-то дополнительно создаваемые индексы.
Я написал что глобал индентичен таблице с двумя полями - аттрибут и его индекс - принципиальной разницы как записать индекс: '25081575/9148502606' или (25081575,9148502606) - нет. После этого Вы захотели узнать а как сделать поиск по полю не первого уровня. У себя вы делаете дополнительную ветвь и дублируете данные. Тоже самое мог бы сделать и я - вставлять еще одну запись индекс которой будет начинаться со второго уровня. Т.е. вместо вставки одной записи
select '25081575/9148502606','qf'
вставлять две
select '25081575/9148502606','qf'
union
select '9148502606/25081575','qf'
Мне кажется дублировать данные это ненормально, да и к тому же при изменении критериев поиска надо переписывать весь код где происходит модификация данных(Жесть (С) Gluk). Поэтому я и предложил как сделать лучше - а именно дополнительный индекс. Очевидно Вы судите по Каше, где создать дополнительный индекс это целая проблема. В SQL это делается немного проще - Вы видели команду. Эта команда выполняется один раз. Дальше уже оптимизатор будет думать использовать его или нет. Команды на модификацию данных не меняются. Если уже были вставлены данные, то не надо вставлять недостающие подветви. Если что индекс можно и удалить.

Хотя шансов что мои слова будут поняты маловато, очевидно кто более-менее сображает из Каше уже давно ушли.


Ко всем остальным:
Зря про FullScan стали писать что это хорошо. Только от темы ушли, а если надо выбрать пару записей из ста миллонов - то это действительно ненормально.
17 ноя 06, 10:49    [3413488]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
SergSuper
Зря про FullScan стали писать что это хорошо. Только от темы ушли, а если надо выбрать пару записей из ста миллонов - то это действительно ненормально.


Когда люди столь радикально заблуждаются - это плохо

2 Sergei Obrastsov

Вы проигнорировали мой вопрос в отношении обеспечения ACID (c)
17 ноя 06, 11:00    [3413605]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Sergei Obrastsov
Нет, не понимаю. Видимо, это новое веяние в РБД - использовать объединенный индекс, чтобы не заморачиваться на отдельные. Впрочем, Full Scan рулит, конечно.
Т.е. просто ответить на вопрос никак нельзя...
Попытка номер три. Как это сделает М-система?
17 ноя 06, 11:00    [3413608]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Rus000
c127
А что там доказывать, на самом деле оценка сложности fullscan=n+F, дерева=log_k(n)+D, где F,D - константы, не зависящие от n. При каком-то соотношении F,D,n может оказаться, что fullscan будет быстрее.


Думаю правильнее fullscan=n*F, дерева=log_k(n)*D, где F,D - константы. Это следует из определения O(fn())

Нет, там именно "+", эти константы обычно не учитываются, поскольку O(fn(n)) это ассимптотическая оценка для n стремящегося в бесконечность и конечные аддитивные константы никого не интересуют. Эти константы есть затраты на подготовку к выполнению алгоритма, от n они не зависят, по крайней мере в теории, чем проще алгоритм тем обычно они меньше. В случае полного перебора и поиска по дереву это выполняется, F<D, отсюда выигрыш перебора на малых n.
17 ноя 06, 11:12    [3413728]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
Gluk (Kazan)
как в Cache реализуется ACID ?

atomicity - откат по журналу, встроенный механизм
consistency - это пишет программист, каше только исполняет программу
isolation - блокировки, пишет программист, каше только синхронизирует выполнение процессов
durability - предзапись и журнал, встроенный механизм автоматического восстановления. остальная часть durability - аппаратно.

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

В частности, в этом и состоит проблема применения автоматических средств типа объектных и sql наворотов поверх мампс. Поскольку в каждой версии соглашения о блокировках это их internals. Лично я нигде в каше не видел четкой декларации какие именно глобалы в какой очередности блокируются при каких операциях sql и объектов. Внутренне в рамках одной версии все операции sql конечно согласованы. Можно посмотреть какой код генерится компилятором sql, но нет никакой гарантии что в следующей версии блокировки будут теми же. Сколько видел применения sql в каше - обычно используется только на чтение, либо обновление идет целиком в sql и в отдельной последовательности tstart-tcommit-trollback, либо приходится догадываться какие оно поставит блокировки чтобы не загнать из-за него всю систему в скажем дедлоки. Да и какой оно выберет план - тоже бабка надвое сказала.

И объектный и sql движок в каше - это довольно сложные механизмы, и не всегда они работают без ошибок. Чтобы исправить проблему в мампс программе - поправил и все, а если ошибка в sql движке - то либо выкручиваться и попытаться угадать что он поймет правильно, либо ждать когда разработчики пофиксят баги. Автоматика, ити иху, с неонкой унутря...

Хотя я не отношу эту проблему к языку sql или к классам, это относится к плохой документированности поведения автоматического движка. Если бы можно было легко понять что оно выставит при исполнении какого выражения - нет проблем, стыковались бы в легкую.
17 ноя 06, 12:23    [3414441]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
SergSuper
А вот теперь делаем индекс по вычисляемому полю и приобретаем то, чего в Каше нет

Увы, уточним - нет в sql и в объектах в каше. В мампсе можно ни в чем себе не отказывать.
17 ноя 06, 12:36    [3414556]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
OS/360
А в Каше можно осоздать временный объект с автоматическим уничтожением?

В локальных переменных. Но что значит автоматическое уничтожение? При завершении процесса локальные переменные процесса пропадают. serial классы, вроде бы это и делают. Можно в принципе в локальных переменных держать и таблицы и индексы, если в хранении таблицы объявить где что лежит. Тогда у каждого процесса будет по своему экземпляру таблицы. Но как указать чтобы при операциях с такими таблицами не применялись блокировки - не знаю.
17 ноя 06, 12:41    [3414605]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
ну я
OS/360
А в Каше можно осоздать временный объект с автоматическим уничтожением?

В локальных переменных. Но что значит автоматическое уничтожение? При завершении процесса локальные переменные процесса пропадают. serial классы, вроде бы это и делают. Можно в принципе в локальных переменных держать и таблицы и индексы, если в хранении таблицы объявить где что лежит. Тогда у каждого процесса будет по своему экземпляру таблицы. Но как указать чтобы при операциях с такими таблицами не применялись блокировки - не знаю.

Разве что в хранении указать такие индексы, чтобы блокировки друг другу не мешали, например
data($j,id)=$lb(Prop1,Prop2)
Тогда разные процессы не будут друг друга клинить. Но блокировки автоматика похоже все равно намерена ставить. Тупица. Если одним словом - то SQL, мать его.
17 ноя 06, 12:45    [3414644]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

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


Понятно, приблизительно так я себе это и представлял
17 ноя 06, 12:56    [3414731]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
ну я
SergSuper
А вот теперь делаем индекс по вычисляемому полю и приобретаем то, чего в Каше нет

Увы, уточним - нет в sql и в объектах в каше. В мампсе можно ни в чем себе не отказывать.

А можно пример как задаются индексы в мампсе и как ими потом пользоваться?
17 ноя 06, 12:56    [3414736]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
SergSuper
ну я
SergSuper
А вот теперь делаем индекс по вычисляемому полю и приобретаем то, чего в Каше нет

Увы, уточним - нет в sql и в объектах в каше. В мампсе можно ни в чем себе не отказывать.

А можно пример как задаются индексы в мампсе и как ими потом пользоваться?

Если кратенько, то тут, справа - это оглавление. Вообще говоря, они не задаются, поскольку метаданных нет.
17 ноя 06, 13:13    [3414873]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
ну я
Если кратенько, то тут, справа - это оглавление. Вообще говоря, они не задаются, поскольку метаданных нет.

Дык всё равно получается это просто паралельное дерево, и этот т.н. индекс надо вручную поддерживать. Т.е. насчет того что можно ни в чем себе не отказывать - мягко говоря, преувеличение

Сообщение было отредактировано: 17 ноя 06, 14:07
17 ноя 06, 14:06    [3415339]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ну я
Member

Откуда: Москва
Сообщений: 1276
SergSuper
ну я
Если кратенько, то тут, справа - это оглавление. Вообще говоря, они не задаются, поскольку метаданных нет.

Дык всё равно получается это просто паралельное дерево, и этот т.н. индекс надо вручную поддерживать. Т.е. насчет того что можно ни в чем себе не отказывать - мягко говоря, преувеличение

Скорее преувеличенные ожидания.
17 ноя 06, 14:27    [3415550]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 33 34 35 36 37 [38] 39 40 41 42 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить