Andrei N.Sobchuck wrote:

>> На HQL это будет выглядеть так: "SELECT human FROM Human human, School
>> sc WHERE human IN sc.students". Гораздо понятнее, лаконичнее и ложится
>> совершенно естественным образом на SQL.
> {ты забыл про возраст}

Спасибо, щас исправим...
"SELECT human FROM Human human, School sc WHERE (human IN sc.students)
AND (human.age <= 27)"

> Кстати, мне кажется, что выборка "Human human" и объединение через
> "human IN sc.students" выглядит понятно в SQL, но не совсем очевидно в
> случае объектов. Ведь нужно что? — у каждой школы, выбрать учеников с
> определённым возрастом.

Да, пример получился искусственным.

> Пример выше с сортировкой на GLORP выглядит так:
>
>glorpSession
> readManyOf: Human
> where: [:each | each school notNIL and: [each age <= 27]]
> orderBy: #surname
>
>
> Совсем не неудобно. Естественно связь Human-2-School нужно задать в
> мапе.

Тот же HQL получается, только записан по-другому.

--
С уважением,
Alex Besogonov (alexy@izh.com)

BaZa wrote:

> C>Тут разве еще не говорили? http://www.hibernate.org/ — OR-mapping для
> C>Java. Поддерживает отображение отношений, _полиморфзм_ (он замечательно
> C>ложится на РСУБД, кстати) и еще кучу фич.
> C>И что характерно — все работает и реально используется.
> Посмотрите этот бенчмарк:
> http://www.middlewareresearch.com/torpedo/results.jsp
> Так что, как видно из результатов, Hibernate не так уж и хорош...

А я могу придумать бенчмарк, где наша внутренняя ORM будет выигрывать.
TORPEDO — это сравнение по скорости, а практика показывает, что 2-3%
оверхеда от Hibernate практически никогда не заметны.

--
С уважением,
Alex Besogonov (alexy@izh.com)

>> Посмотрите этот бенчмарк:
>> http://www.middlewareresearch.com/torpedo/results.jsp
>> Так что, как видно из результатов, Hibernate не так уж и хорош...

C>А я могу придумать бенчмарк, где наша внутренняя ORM будет выигрывать.
C>TORPEDO — это сравнение по скорости, а практика показывает, что 2-3%
C>оверхеда от Hibernate практически никогда не заметны.

Дело в том, что я лишь хотел показать, что Hibernate это не панацея, как привыкли думать у нас, в России.
А насчет бенчмарка, то я тоже могу придумать такую ситуацию, в которой наша "proprietary O/R Mapping Tool" сделает все остальные...
Но как насчет таких пунктов как Scalable, Flexible (и даже Modular и EasyToUse)?

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

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

C>Ну так и рассматривайте RDB как _хранилище_ информации, с которой вполне
C>можно работать в ООП-стиле.
И строить запросы по состоянию, то бишь нарушать инкапсуляцию? Вообще, если говорить по правде, то я отнюдь не против ORM. Но то, что ООБД на несколько порядков эффективнее выполняют эту задачу — это правда.


>> C>Наследование и
>> C>полиморфизм замечательно выражаются в RDB в виде объединенных по PK
>> C>таблиц (возможно с полями-дискриминаторами).
>> Это всего лишь один из самых простых и самых неэффективных способов
>> маппирования объектов в RDBMS.

C>В ООБД оно представляется точно таким же образом
Не есть правда. Ты сам ложишь ссылки на Hibernate, ну и посмотри в возможные значения метаданных. Там только одно плохо. Смешивать различные виды связывания parent-child для типа — нельзя.

C>Ничего особо не нужно на практике. Берется Hibernate, пишется
C>mapping-файл (этот шаг можно пропустить и сгенерировать его из описания
C>БД или из Java-классов). Удаленность БД, конечно, сказывается, но далеко
C>не фатально — в реальности все работает более чем удовлетворительно.
Удовлетворительно для определенного класса задач. Во других классах задач приходится переходить на чистый SQL без объектной схемы. Потому как фатально получается. Реляционки не очень приспособлены к навигационному доступу ни в плане межсерверных вызовов, ни в плане быстрого выполнения запроса (обработка SQL — тяжелая задача и также требуется быстрая прямая адресация объекта). Поэтому и говорю об эффективности.
Еще проблемка для размышления. Синхронизация объектной модели и запросов — проблема не решена.
Например(пишу примерно).
//получаем объект
select * from ldobj where name='AAA';
....
obj.Name='BBB';
....
select * from ldobj where name='BBB';
а такого объекта нет. Потому как не сохранен и существует только в кэш.

С уважением, Gleb.

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

C>А я могу придумать бенчмарк, где наша внутренняя ORM будет выигрывать.
C>TORPEDO — это сравнение по скорости, а практика показывает, что 2-3%
C>оверхеда от Hibernate практически никогда не заметны.

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

BaZa wrote:

> C>А я могу придумать бенчмарк, где наша внутренняя ORM будет выигрывать.
> C>TORPEDO — это сравнение по скорости, а практика показывает, что 2-3%
> C>оверхеда от Hibernate практически никогда не заметны.
> Дело в том, что я лишь хотел показать, что Hibernate это не панацея,
> как привыкли думать у нас, в России.
> А насчет бенчмарка, то я тоже могу придумать такую ситуацию, в которой
> наша "proprietary O/R Mapping Tool" сделает все остальные...

Не панацея, конечно, но ООЧЕНЬ близко к этому

> Но как насчет таких пунктов как Scalable, Flexible (и даже Modular и
> EasyToUse)?

Modular — на "4", EasyToUse — "5", Flexible — "4", Scalable — "5".

> За удовлетворение всем таким требованиям и можно поступится
> быстродействием в конкретной задаче, и получить универсальный
> инструмент...

Я работал немного с Versant в свое время — Hibernate его (по моим
ощущениям) намного превосходит в удобстве.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

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

V>>СУБД — это ср-во хранения больших объемов данных на ВНЕШНЕМ носителе таким образом, чтобы обеспечивать быстое извлечение необходимых данных в оперативную память. Для организации этого мы используем ЛОГИЧЕСКОЕ проедставление данных, ключи, индексы (уменьшающие размер ВНЕШНЕЙ памяти, требуемый для поиска) и пр.
GZ>Ошибка. Индексы предназначены не только для увеличения hit-ratio. Индексы — это способ убыстрения доступа к данным со сложностью O(NlogN) или O(1) для хешей. Это говорит о обязательности индекса при наличии большого количества объектов. А БД работает именно с большим кол-вом объектов.

ну и где мое высказывание противоречит твоему замечанию
могу еще пройтись по твоим индексам со сложностью поиска O(NlogN) для физического хранения... какой здравомыслящий человек будет использовать последовательный индекс при хранении в памяти больших наборов данных? кеши рулят...

Здравствуйте, Cyberax, Вы писали:
C>Кроме того, рекомендую прочитать документацию по Hibernate, чтобы потом
C>не натыкаться на такие "несуществующие" решения.
Нда... Если обзывать "полиморфизмом" возможность возврата всех наследников класса одним запросом, то, конечно, все будет здорово.
C>Я _уже_ год _на_ _практике_ работаю с полиморфными объектами в БД.
C>Никаких особых проблем.
Круто. И как там в Hibernate с поддержкой запросов, в которых предикаты полиморфны? Нормально? Или там в предикатах тоже методы вызывать запрещено?

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

Ты хочешь сказать, что описав алгоритм Accepts методов в каждом из классов при помощи императивного языка, ты потом сможешь соптимизировать запрос, типа:

select * from Events e where e.Accepts(@me)

чтобы у него была производительность лучше чем O(n). Причем как ты сам же утверждаешь — для нетривиальных случаев, то есть для сложного алгоритма в Accepts.

Ню ню. Флаг тебе в руки и т.д.
ИМХО, ты этого сделать не сможешь. И это даже не вопрос построения СУБД, это вообще вопрос оптимизации императивных языков программирования, которой на практике — нет и не предвидится, хотя компиляторов понаделано — море. И ни один из них даже инлайнить виртуальные функции не умеет. Потому что — это бред, если подумать.

Вот такая вот постановка вопроса! Если ты не можешь этого сделать, то вся декларируемая тобой поддержка полиморфизма — ничего не стоит.

---

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

Это вторая точка зрения.

---

И еще одна точка зрения на процедуры в запросах:

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

Именно исходя из возможности оптимизации синтаксис и семантика SQL и были разработаны. Именно поэтому выполнение хранимых процедур в SQL (даже без полиморфизма) — есть зло.

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

---

Ну и в заключении повторюсь, что ИМХО, ты не сможешь сделать оптимизатор запросов с использованием императивного языка для описания методов объектов, чтобы достичь практически значимой вероятности оптимизации запросов. Это даже не говоря о полиморфизме.
А без этого все твои идеи ничего оригинального не представляют, так как все это уже есть, например, в Oracle 9i. И тормозит там все так, как и логично было бы предположить.

---

Ну и на самый последок: Все эти проблемы давно известны. И единственный выход, который я вижу — это некий компромисс: разделение СУБД и сервера приложений, и как следствие уменьшение требований к СУБД. И может быть, усложнение написания программ с точки зрения прикладного программиста, чтобы добиться возможности оптимизации запросов.
И в этом свете действительно разница между РСУБД и ООСУБД небольшая.

Так что решение здесь должно быть чисто организационное, на более высоком уровне абстракции, с точки зрения всей системы в целом, а не только СУБД.

Еще один путь — снизить требования к ООСУБД. Например, сделать как в Delphi. Там в формах сохраняются свойства, а не поля. То есть, некоторая инкапсуляция есть. Вот и сделать так, чтобы сохранялись свойства, и в языке запросов оперировать свойствами. Это по моему вполне реальный путь.

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

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

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

V>>>СУБД — это ср-во хранения больших объемов данных на ВНЕШНЕМ носителе таким образом, чтобы обеспечивать быстое извлечение необходимых данных в оперативную память. Для организации этого мы используем ЛОГИЧЕСКОЕ проедставление данных, ключи, индексы (уменьшающие размер ВНЕШНЕЙ памяти, требуемый для поиска) и пр.
GZ>>Ошибка. Индексы предназначены не только для увеличения hit-ratio. Индексы — это способ убыстрения доступа к данным со сложностью O(NlogN) или O(1) для хешей. Это говорит о обязательности индекса при наличии большого количества объектов. А БД работает именно с большим кол-вом объектов.

V>ну и где мое высказывание противоречит твоему замечанию
Это дополнение которое перечеркивают твое следующее высказывание

Тогда ООП-хранилища и "покажут" этой реляционке, с ее суррогатными ключами и индексами.

V>могу еще пройтись по твоим индексам со сложностью поиска O(NlogN) для физического хранения... какой здравомыслящий человек будет использовать последовательный индекс при хранении в памяти больших наборов данных? кеши рулят...
Я. Может я и не здравомыслящий, но для алгоритмов с большим набором данных строить B+ индекс(или хотя бы чистый бинарник) — первое дело. Иметь одновременно сортированный список с быстрым доступом и вставкой, с возможностью адаптирования доступа алгоритмов по некоторому range — не самое плохое предприятие.
А учитывая то, что мы работаем потенциально с большим набором данных — то расходы на B+ на порядок меньше чем расходы на тупой доступ к миллионам объектов.

С уважением, Gleb.
PS: только не надо намекать на хеши Net. Оссобенно в связи с их тактикой пересчета хеша. Для больших данных — это нереальный алгоритм.

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

V>>ну и где мое высказывание противоречит твоему замечанию
GZ>Это дополнение которое перечеркивают твое следующее высказывание
GZ>

GZ>Тогда ООП-хранилища и "покажут" этой реляционке, с ее суррогатными ключами и индексами.

Не смотришь в корень или я недостаточно выразил свою мысль. Мне, например, непонятно назначение индекса по суррогатному (логическому) ключу, если мне не нужен сам суррогатный ключ. ForeignKey иже с ним.

V>>могу еще пройтись по твоим индексам со сложностью поиска O(NlogN) для физического хранения... какой здравомыслящий человек будет использовать последовательный индекс при хранении в памяти больших наборов данных? кеши рулят...
GZ>Я. Может я и не здравомыслящий, но для алгоритмов с большим набором данных строить B+ индекс(или хотя бы чистый бинарник) — первое дело. Иметь одновременно сортированный список с быстрым доступом и вставкой, с возможностью адаптирования доступа алгоритмов по некоторому range — не самое плохое предприятие.

А я намекал как раз на хеш-способ организации этих самых индексов в ФИЗИЧЕСКОЙ памяти. Ибо как раз они дают быстрый доступ и вставку. Немного непонятно, как ты собрался быстро вставлять в B-индекс? Если я не ошибаюсь, то надо двигать в памяти все миллионы вхождений индексируемого значения?

GZ>PS: только не надо намекать на хеши Net. Оссобенно в связи с их тактикой пересчета хеша. Для больших данных — это нереальный алгоритм.

Ну да, они там размер основной таблицы хеша пересчитывают при росте количества данных. Однако же, у тебя есть возможность указать в конструкторе таблицы как предполагаемый размер данных, так и LoadFactor. Жаль, что эти параметры можно указать только в конструкторе. Однако, если тебе надо поменять размер индекса на много, то можно смело создавать новую хеш-таблицу для индекса и "перелить" в нее индексы. Стоимость этой операции практически равна внутреннему rehash(), однако ты сделаешь это однократно. (если не создать сразу таблицу необходимого размера, то rehash может быть выполнен неоднократно).

Хотя, говоря начистоту, мне способ реализации дотнетной хеш-таблицы не нравится. Мне больше нравится способ, где в каждом вхождении основной хеш-таблицы хранится сортированный массив. Подобные хеш-таблицы лучше предназначены для активной вставки/удаления большого числа элементов. Если будет не лень, то напишу подобный хеш и выложу для всеобщего пользования. (Писал когда-то именно такой на С++, ибо std::map не удовлетворял на больших наборах)

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

S>Здравствуйте, BaZa, Вы писали:
BZ>>Мне просто, например, интересно, так ли необходимо хранение методов в ООСУБД (как в Gemstone и O2)?
S>Ну, вообще-то, лично я бы постеснялся назвать базу без хранения методов объектно-ориентированной. Поскольку из пяти концепций объектно-ориентированного программирования поддерживаются только две: идентифицируемость и наследование. О поведении, вместе с инкапсуляцией и полиморфизмом, можно забыть. Не вполне очевидно, нужно ли вообще наследование без полиморфизма.

Это вопрос проектирования.
В трехзвенке будет храниться код в исполняемых файлах на стороне сервера, и какая разница клиенту.
Или архитектура вроде Oracle Forms, когда приложения целиком хранятся на сервере СУБД.
То есть с уровнем "объектно-ориентированности" движка СУБД прямой связи нет.
Если подумать — найдется способ, как запихнуть код поближе к объекту, вопрос для чего, с какой целью.

Здравствуйте, Михаил, Вы писали:
М>Это вопрос проектирования.
М>В трехзвенке будет храниться код в исполняемых файлах на стороне сервера, и какая разница клиенту.
М>Или архитектура вроде Oracle Forms, когда приложения целиком хранятся на сервере СУБД.
М>То есть с уровнем "объектно-ориентированности" движка СУБД прямой связи нет.
М>Если подумать — найдется способ, как запихнуть код поближе к объекту, вопрос для чего, с какой целью.
В частности, для того, чтобы работали нормальные запросы. В современных ОРМ системах это не так. Чтобы вызвать полиморфный метод, объект надо "поднять" в кэш. Чтобы выполнить поиск объектов по предикату, их нужно "спустить" в СУБД. Мы не обсуждаем клиента. Клиенту вообще торчит только SOAP сервис, и ему наплевать есть ли там внутри СУБД.

Здравствуйте, vdimas, Вы писали:
V>А я намекал как раз на хеш-способ организации этих самых индексов в ФИЗИЧЕСКОЙ памяти. Ибо как раз они дают быстрый доступ и вставку. Немного непонятно, как ты собрался быстро вставлять в B-индекс? Если я не ошибаюсь, то надо двигать в памяти все миллионы вхождений индексируемого значения?
Ошибаешься. Во-первых, B+ дерево имеет логарифмическое время выполнения всех операций — вставки, удаления, и поиска. Ничего двигать вообще не надо. Хэши, применяемые в СУБД, устроены совсем не так, как ты привык видеть в памяти. Потому что там rehash с переливанием, предлагаемый тобой — это выстрел себе в ногу. Рекомендую ознакомиться с литературой. Например, есть неплохая книга Гарсиа-Молина со товарищи.

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

S>Здравствуйте, Михаил, Вы писали:
М>>Это вопрос проектирования.
М>>В трехзвенке будет храниться код в исполняемых файлах на стороне сервера, и какая разница клиенту.
М>>Или архитектура вроде Oracle Forms, когда приложения целиком хранятся на сервере СУБД.
М>>То есть с уровнем "объектно-ориентированности" движка СУБД прямой связи нет.
М>>Если подумать — найдется способ, как запихнуть код поближе к объекту, вопрос для чего, с какой целью.
S>В частности, для того, чтобы работали нормальные запросы. В современных ОРМ системах это не так. Чтобы вызвать полиморфный метод, объект надо "поднять" в кэш. Чтобы выполнить поиск объектов по предикату, их нужно "спустить" в СУБД. Мы не обсуждаем клиента. Клиенту вообще торчит только SOAP сервис, и ему наплевать есть ли там внутри СУБД.

По-моему, запросы хорошо работают, когда есть быстрые индексы, оптимизация алгоритма выборки и т.п.
То есть скорость запроса — это структура данных, связи между объектами, алгоритмы поиска и сортировки, наконец параметры железа. Но только не наличие или отсутсвие хранимых функций у объектов.
С такой точки зрения вообще все равно, в каком формате выполняемый код хранится.
Преимущества одного формата над другим — поведение в условиях многозадачности, большого количества активных юзеров, параллельных транзакций, также объектов БД — их типов и экземпляров.

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

Это почти ObjectStore. С нормальным С++. И с транзакциями.
Правда, с SQL там туговато...

V>я бы не отказался в коде писать нечто (некий С++ — подобный язык, например):
V>

V>[key<number>]
V>[persist]
V>struct MyDocRow : DbRow {
V>    int number;

V>    [index(SortAsc)]
V>    date docDate;

V>    int state;
V>};

V>[persist]
V>struct MyDocDetail : DbRow {
V>    refRow<MyDocRow> doc;
    
V>    money rowSum;
V>};


V>bool filter1(MyDocRow& docRow) { return state==5; };

V>struct filter2 {
V>   money threshold;
V>   filter2(money threshold) {this.threshold = threshold; }
V>   bool operator()(MyDocDetail& docDetail) { return rowSum>=threshold; }
V>}

V>[...]

V>struct DocSums : TmpRow {
V>    int docNumber;
V>    money docSum;    

V>    static Calculate(MyDocRow& docRow, Enumerator<MyDocDetail> detail) {
V>        docNumber = row.number;
V>        docSum = agregate_sum<MyDocDetail::rowSum>(detail);
V>    }
V>}

V>// целевой алгоритм
V>Enumerator<DocSums> GetDocSums(money threshold, date date1, date date2) {
V>    Enumerator<MyDocRow> docEnumerator = sort<MyDocRow::number, SortAsc>(seek(ByIndex<MyDocRow::docDate>(date1, date2)), filter1);
V>    NestedEnumerator<MyDocRow, MyDocDetail> docWithDetailEnumerator = join<MyDocDetail::doc>(docEnumerator, filter2(threshold));

V>    return transform<DocSums>(docWithDetailEnumerator, DocSums::Calculate);
V>}
V>

Здравствуйте, Михаил, Вы писали:
М>По-моему, запросы хорошо работают, когда есть быстрые индексы, оптимизация алгоритма выборки и т.п.
Да.
М>То есть скорость запроса — это структура данных, связи между объектами, алгоритмы поиска и сортировки, наконец параметры железа. Но только не наличие или отсутсвие хранимых функций у объектов.
Мы говорим про возможность формулировать запросы.
М>С такой точки зрения вообще все равно, в каком формате выполняемый код хранится.
Если его нельзя использовать в запросах — не все равно.
М>Преимущества одного формата над другим — поведение в условиях многозадачности, большого количества активных юзеров, параллельных транзакций, также объектов БД — их типов и экземпляров.
Нет. Эти преимущества уже давно получены. Теперь надо получить преимущество в скорости разработки. ORM добавляет много рутинной работы.

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

М>>С такой точки зрения вообще все равно, в каком формате выполняемый код хранится.
S>Если его нельзя использовать в запросах — не все равно.
М>>Преимущества одного формата над другим — поведение в условиях многозадачности, большого количества активных юзеров, параллельных транзакций, также объектов БД — их типов и экземпляров.
S>Нет. Эти преимущества уже давно получены. Теперь надо получить преимущество в скорости разработки. ORM добавляет много рутинной работы.

Кажется, я не совсем понимаю, что надо такого, чего для щастья не хватает принципиально. Пример в студию?

Здравствуйте, Михаил, Вы писали:
М>Кажется, я не совсем понимаю, что надо такого, чего для щастья не хватает принципиально.
Вижу.
М>Пример в студию?
Re[23]: Объектные базы как они есть

Автор: Sinclair
Дата: 07.04.05

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

V>Не смотришь в корень или я недостаточно выразил свою мысль. Мне, например, непонятно назначение индекса по суррогатному (логическому) ключу, если мне не нужен сам суррогатный ключ. ForeignKey иже с ним.
Очень простая причина. Уменьшение кол-ва задействованных объектов в алгоритме. Что касается foreignkey — то это не только правило ссылочной целостности, но и суррогатный индекс на ссылаемый аттрибут для быстрого его выполнения.

V>А я намекал как раз на хеш-способ организации этих самых индексов в ФИЗИЧЕСКОЙ памяти. Ибо как раз они дают быстрый доступ и вставку. Немного непонятно, как ты собрался быстро вставлять в B-индекс? Если я не ошибаюсь, то надо двигать в памяти все миллионы вхождений индексируемого значения?
Нет при вставке двигаются только в одно сегменте. То есть сложность почти как при поиске. При нехватке места — значения балансируются с соседними сегментами. Но он ни для одной операции не задействует все сегменты со значениями(кроме создания самого дерева, конечно).

GZ>>PS: только не надо намекать на хеши Net. Оссобенно в связи с их тактикой пересчета хеша. Для больших данных — это нереальный алгоритм.

V>Ну да, они там размер основной таблицы хеша пересчитывают при росте количества данных. Однако же, у тебя есть возможность указать в конструкторе таблицы как предполагаемый размер данных, так и LoadFactor. Жаль, что эти параметры можно указать только в конструкторе. Однако, если тебе надо поменять размер индекса на много, то можно смело создавать новую хеш-таблицу для индекса и "перелить" в нее индексы. Стоимость этой операции практически равна внутреннему rehash(), однако ты сделаешь это однократно. (если не создать сразу таблицу необходимого размера, то rehash может быть выполнен неоднократно).
У меня есть индексы размером в несколько мегабайт(даже больше сотни). Так что эта операция не очень быстрая.

V>Хотя, говоря начистоту, мне способ реализации дотнетной хеш-таблицы не нравится. Мне больше нравится способ, где в каждом вхождении основной хеш-таблицы хранится сортированный массив. Подобные хеш-таблицы лучше предназначены для активной вставки/удаления большого числа элементов. Если будет не лень, то напишу подобный хеш и выложу для всеобщего пользования. (Писал когда-то именно такой на С++, ибо std::map не удовлетворял на больших наборах)
Каким образом ты собрался сортировать строки. Для хеша важно нормальное распределение значений. Для нормального распределения нужен функция хеширования. Но я не знаю функций хеширования которая могла бы оставлять информацию о порядке для сортировки.

С уважением, Gleb.