Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> Вообще вариант с описанием и алгоритмом Расширяемое хэширование есть у Бакнела хорошая кстати книга. Весь алгоритм умещается на 2-3 страницах.
M>Со сбросом страниц на диск?
Вроле Да, во всяком случае это не проблема. Но наверное погорячился на 4-5 страницах. А если честно, то я особо не разбирался. Понял алгоритм, взял на заметку, но неболее, по причине малой пригодности. Есть другие подходы, но они не для широкого использования, а под задачу.
S>> Некорректно потому что был поставлен вопрос " А вот работающий алгоритм для диска я пока не услышал"
M>Еще раз тебе говорю. Просто алгоритм для диска не интересен.
Ну не ты же ставил вопрос Надеюсь, что этот алгоритм был услышан
S>> при этом было указано, что больших бенефитов при этом не наблюдается.
M>Во-во.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> В чем разница Между навигационный доступ и последовательного????
M>Тебе это надо объяснять?
Да потому, что я могу засасывать данные постранично. Навигационный доступ это доступ через курсор. Единственное его отличеие от SQL прохода по данным, в том что для него нужен буфер для копирования из считанной страницы.
Учитывая что файловая система сама кэширует файлы, то все затраты выходящие на копирование составляют гдето 400 мб/сек.
Что при проходе по 2 ГБ базе без учета вычислений, поднятия страниц иьд всего 5 сек.
А вот при проходе по индексу учитывая косвенность доступа к записи, то в процентах откомпиленный SQL запрос выигрывает очень мало.

А вот в настольной БД использование кластерного индекса вполне приемлемо.
S>> Чем пробег по индексу ДБФ отличается от SQL го пробега. Чем ручная реализация будет отличаться от схемы запроса реализуемой SQL, чем будет отличаться код когда нужно прыгать по сылкам, как на родео итд. ???
M>Вот этого пассажа я вообще не понял.

S>> Навигационный доступ для локальных БД более чем приемленный. Я им только и пользуюсь.
M>Пользуйся.
И на том спасибо.

Здравствуйте, stalcer, Вы писали:

S>В силу ряда организационных причин, таких как частое изменение программ в связи с изменениями бизнес процессов или законодательства, а также криворукость среднестатистического программиста, автоматический сбор и анализ статистики и последующее ее использование для автоматического построения запросов может привести к увеличению производительности в конечном итоге.
S>Причем заметь, одновременно с удобством программирования.


S>А я здесь, всю таблицу B и не вытаскиваю. Я вытаскиваю всю таблицу A. Ну или можно не всю, добавь where на свой вкус, но только для A.
S> Таблица B здесь — это дополнительная, связанная с основной информация, например адрес-клиента.
Тогда ты pk и fk местами перепутал.

Здравствуйте, Serginio1, Вы писали:

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

S> Учитывая что файловая система сама кэширует файлы, то все затраты выходящие на копирование составляют гдето 400 мб/сек.
Какое копирование?

S> Что при проходе по 2 ГБ базе без учета вычислений, поднятия страниц иьд всего 5 сек.
Ты предлагаешь всю базу в память поднять?

S> А вот при проходе по индексу учитывая косвенность доступа к записи, то в процентах откомпиленный SQL запрос выигрывает очень мало.
Расскажи это разработчикам реляционных СУБД. Причем всем.

S> А вот в настольной БД использование кластерного индекса вполне приемлемо.
Очень интересно посмотреть на выгоды от использования кластерного индекса на основе хэш-таблицы.

Здравствуйте, Merle, Вы писали:

M>Тогда ты pk и fk местами перепутал.

Вроде нет . Я вот что хотел сказать то: есть модель:

public class Client
{
  public long    id;
  public string  name;
  public Address addressId;
}

public class Address
{
  public long id;
  //...
}

И запрос:

select * from Client c left join Address a on a.id = c.addressId where c.name like '...'

Здравствуйте, AndrewVK, Вы писали:

AVK>Но не до беспредела. У меня на машине 2гига оперативки, и я согласен если БД сожрет лишнюю сотню мег, если при этом она будет работать ощутимо быстрее.

Так ты что, делаешь БД только для себя?

У меня на машине 777 метров, загружены две студии 2005, 3 ворда, outlook, vss. Периодически поднимаются свои приложения в режиме отладки. Слоты для памяти, кончились, официально хрен выпишешь. Janus поднимать на работе боюсь. Не до него, свои бы не тормозили. Так что если лишнюю сотню будет занимать outlook, или icq — я не согласен. IMHO. Одно из бенефитов встроенной базы данных должно быть то, что ты можешь работать с массивом информации с достаточно низким потреблением оперативной памяти.

Здравствуйте, Merle, Вы писали:

M>Блин! Да кто говорит, что сохранять нельзя? Храни пожалуйста, никто не мешает, хоть гигабайт — никаких проблем.
M>Даже индекс построить можно по первому килобайту.
M>Еще раз спрашиваю, что ты искать-то собрался в B+, в письмах, по ключу такого размера??

like '%Письмо%С уважением, Буратино%'

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> Да потому, что я могу засасывать данные постранично.
M>А что толку, если у тебя данные на странице в полном беспорядке лежат?
Относительо индекса или по какому признаку они должны быть упорядочены???
В кластерном индесе все упорядочено.

S>> Учитывая что файловая система сама кэширует файлы, то все затраты выходящие на копирование составляют гдето 400 мб/сек.
M>Какое копирование?
Копирование записи в буфер. Если при компилировании запроса проход может осуществляется по страницам напрямую, то для курсора нужно из этих страниц скопировать в буффер.

S>> Что при проходе по 2 ГБ базе без учета вычислений, поднятия страниц иьд всего 5 сек.
M>Ты предлагаешь всю базу в память поднять?
Это пример если вся база закэширована. Все зависит от файловой системы и количества памяти.
S>> А вот при проходе по индексу учитывая косвенность доступа к записи, то в процентах откомпиленный SQL запрос выигрывает очень мало.
M>Расскажи это разработчикам реляционных СУБД. Причем всем.
Не, ты это мне скажи и докажи. А мне им нечего доказывать, т.к. выбор мой отнюдь не в их пользу, как впрочем и достаточно большого круга пользователей использующие терминальные сессии и локальные БД, и использующие все премущества навигационного доступа. На продолжительном отрезке времени. Да и тема "Настольная БД".
S>> А вот в настольной БД использование кластерного индекса вполне приемлемо.
M>Очень интересно посмотреть на выгоды от использования кластерного индекса на основе хэш-таблицы.
А причем здесь Хэш таблица??? Хотя ради некой истины. В чем премущество хранения данных в кластерном индексе по ПК??? От аналогичной в хэш таблице???

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Merle, Вы писали:

M>>Блин! Да кто говорит, что сохранять нельзя? Храни пожалуйста, никто не мешает, хоть гигабайт — никаких проблем.
M>>Даже индекс построить можно по первому килобайту.
M>>Еще раз спрашиваю, что ты искать-то собрался в B+, в письмах, по ключу такого размера??

GZ>

GZ>like '%Письмо%С уважением, Буратино%'
GZ>

Нужно регулярные выражения подключать
А зачем вообще здесь нужен индекс??? Первые символы вроде как не используются

Здравствуйте, GlebZ, Вы писали:

GZ>

GZ>like '%Письмо%С уважением, Буратино%'
GZ>

Ты всерьез веришь, что B+ индексы тебя спасут? В лучшем случае некоторые сервера распознают like, в котором фиксированное начало. То, что ты хочешь, называется полнотекстовый поиск, и его делают совсем совсем иначе.

Здравствуйте, GlebZ, Вы писали:

AVK>>Но не до беспредела. У меня на машине 2гига оперативки, и я согласен если БД сожрет лишнюю сотню мег, если при этом она будет работать ощутимо быстрее.

GZ>Так ты что, делаешь БД только для себя?

Нет, но у Висты рекомендуемый объем памяти 1 гиг, а для premium редакции 2 гига. Вот так вот.

GZ>У меня на машине 777 метров, загружены две студии 2005, 3 ворда, outlook, vss.

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

GZ>Одно из бенефитов встроенной базы данных должно быть то, что ты можешь работать с массивом информации с достаточно низким потреблением оперативной памяти.

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

Здравствуйте, Serginio1, Вы писали:

S>>> Некорректно потому что был поставлен вопрос " А вот работающий алгоритм для диска я пока не услышал"
M>>Еще раз тебе говорю. Просто алгоритм для диска не интересен.
S> Ну не ты же ставил вопрос

Читать надо весь топик, а не цепляться к словам. Речь шла об алгоритме, который был бы быстрее В+, а не вобще.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

S>>>> Некорректно потому что был поставлен вопрос " А вот работающий алгоритм для диска я пока не услышал"
M>>>Еще раз тебе говорю. Просто алгоритм для диска не интересен.
S>> Ну не ты же ставил вопрос

AVK>Читать надо весь топик, а не цепляться к словам. Речь шла об алгоритме, который был бы быстрее В+, а не вобще.
Ну дык был показан этот самый алгоритм. Кроме того, при достижении большого размера, хэш таблица может плавно переходить в Б+ дерево, получая нужную универсальность. На самом деле переходных алгоритмов хорошо работающих в определенных диапозонах достаточно много, униврсальные не всегда быстры и свежи.
На самом деле я не цепляюсь. Честно. Но сам алгоритм Extendible Hashing мне лично очень нравится.

Здравствуйте, Serginio1, Вы писали:

S> Относительо индекса или по какому признаку они должны быть упорядочены???
Ключи индекса должны быть упорядочены.

S> В кластерном индесе все упорядочено.
Как упорядочены — у тебя же хэш, а он порядка не гарантирует.

S> Это пример если вся база закэширована. Все зависит от файловой системы и количества памяти.
Ну-ну..

S> Не, ты это мне скажи и докажи.
Зачем? Я и так уже устал мыслью по древу растекаться...

S> А причем здесь Хэш таблица???
Ну ты же ее использование отстаиваешь... Или уже передумал?

S> В чем премущество хранения данных в кластерном индексе по ПК???
Кластерный индекс по PK создается в очень редких случаях.

Здравствуйте, stalcer, Вы писали:

S>Вроде нет . Я вот что хотел сказать то: есть модель:
Это модель классов... А модель в БД будет такой:

CREATE TABLE client(ID_Client int IDENTITY PRIMARY KEY, name nvarchar(100))
CREATE TABLE address(ID_Address int IDENTITY PRIMARY KEY, ID_Client int, street...)

Ну и запрос соответственно:

SELECT * FROM Client C LEFT JOIN Address A ON C.ID_Client = A.ID_Client WHERE C.Name...

При этом у тебя в модели ошибочка по логике вещей должно быть:

public class Client
{
  public long    id;
  public string  name;
  public Address[] addresses;
}

Так как адресов у клиента вполне может быть несколько.... И вся основная нагрузка ложится на аккуратно упорядоченный FK.

Здравствуйте, GlebZ, Вы писали:

GZ>

GZ>like '%Письмо%С уважением, Буратино%'
GZ>

Хм.. Глеб, ну, это... нет слов..

Чем здесь, по твоему, поможет B+?

Здравствуйте, Serginio1, Вы писали:

AVK>>Читать надо весь топик, а не цепляться к словам. Речь шла об алгоритме, который был бы быстрее В+, а не вобще.
S> Ну дык был показан этот самый алгоритм.

Ничего там не было показано. Был показан алгоритм, который, как мне кажется, как минимум не лучше В+, если не хуже.

S> Кроме того, при достижении большого размера, хэш таблица может плавно переходить в Б+ дерево, получая нужную универсальность.

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

S> На самом деле я не цепляюсь. Честно. Но сам алгоритм Extendible Hashing мне лично очень нравится.

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

Здравствуйте, Merle, Вы писали:

S>> А вот в настольной БД использование кластерного индекса вполне приемлемо.
M>Очень интересно посмотреть на выгоды от использования кластерного индекса на основе хэш-таблицы.
Очень интересно посмотреть на выгоды от использования кластерного индекса на основе guid.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, GlebZ, Вы писали:

GZ>>Здравствуйте, Merle, Вы писали:

M>>>Блин! Да кто говорит, что сохранять нельзя? Храни пожалуйста, никто не мешает, хоть гигабайт — никаких проблем.
M>>>Даже индекс построить можно по первому килобайту.
M>>>Еще раз спрашиваю, что ты искать-то собрался в B+, в письмах, по ключу такого размера??

GZ>>

GZ>>like '%Письмо%С уважением, Буратино%'
GZ>>

S> Нужно регулярные выражения подключать
S> А зачем вообще здесь нужен индекс??? Первые символы вроде как не используются
Обломс. Согласен. Буду жрать крокодилов и пить уксус.

Здравствуйте, AndrewVK, Вы писали:

AVK>Ты всерьез веришь, что B+ индексы тебя спасут? В лучшем случае некоторые сервера распознают like, в котором фиксированное начало. То, что ты хочешь, называется полнотекстовый поиск, и его делают совсем совсем иначе.
Да я то вполне понимаю(и про ошибочку с like понимаю ). Но наверняка начнутся привязки системы поиск к несвойственным ему полям. Другого пути то нет. Есть поле comments, в который кладут некоторый коментарий. И захотелось программеру сделать по нему поиск. Обычно комментс в районе 200-300 байт(если не null), но один коммент — 2000 кила. Ошибка вывалится то у пользователя, и что делать? Какой нибудь рычаг о том, что структура выходит за пределы индекса нужен. Пуская программер обрабатывает его по своему усмотрению. Но он нужен.