Електронен речник в Делфи

Здравейте. Получих задачата да разработя речник на определени термини с описание, с бързо търсене. Като Лингво. Сега речникът е в документ на Excel, има около 100 хиляди думи.Сега имам въпрос как да съхранявам набор от думи и техните описания. За тестване вкарах речника в XML документ, с 2 атрибута, дума + описание. След това направих интерфейс, където Listbox се намира във формуляра, в който зареждам (обекти) думи от XML документ (използвайки XMLDoc средства). Самото изтегляне отнема много дълго време.
Моля, посъветвайте по-бързо решение на този проблем и повече речници ще трябва да бъдат криптирани. Благодаря.

Hash_words (цяло число, първичен ключ)
Шифрована_дума (BLOB)
Encrypted_description_word (BLOB)

Бих го съхранил в двоична форма. заредени незабавно.

от базата данни работех само с Orakl и MySQL, за малък речник не бих искал да вдигам сървъри или да стартирам допълнителни услуги.


> Бих го запазил в двоична форма. заредени незабавно.

Може да е малко по-подробна или ключови думи за търсене. Благодаря.

За ускоряване на търсенето (чрез хеш на думата, а не само по себе си).


> Скоростта на търсене в такова нещо е O (N), където N е броят на думите.

Хешовете могат да бъдат сортирани във възходящ ред . Тогава ще намерите този, от който се нуждаете, още по-бързо.


> Така или иначе зависимост от количеството.

Вече няма пряка връзка.
И ако направите блокове от вече сортирани данни (да кажем блок от хеш от 1000 до 5000), тогава направете двоично търсене в тези блокове, тогава необходимият хеш ще бъде намерен много, много бързо.
Тези. първо намираме блока от диапазона, в който се намира този хеш. И след това двоично търсене.

Не мисля, че ще е по-бавен от дървото.

С текущото количество памет можете да попълните таблицата, но поне 1/10 - няма да има зависимост от N.

Не се случи магия. броят на сблъсъците отново зависи от общия брой елементи. Разширяването на списъка за неопределено време също не е най-добрият вариант.
Между другото, книгата е така-така. бинарното търсене може да се извърши без никакви сравнения.

О Беше запечатан. не двоично, а дърво

броят на сблъсъците зависи от функцията за хеширане и от съотношението N/Length (hash_array) - има 100 хиляди в речника, направете размера на масива равен на милион, както вече писах, допълнителните 4 MB на специална роля пусни го.

Каква идея за оправяне с дърво?


> Моля, посъветвайте по-бързо решение за това
> задачи и повече речници ще трябва да бъдат криптирани. Благодаря.
>

Дърво на префикс в естествен двоичен формат.

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

В интерес на интереса отворих два речника: англо-руски Мюлер и руски речник Ожегов. В първата 70 000 статии, във втората 52 000.
За днешните компютри това са семена, освен ако, разбира се, те не се съхраняват като XML и се зареждат в списъчна кутия. Без никакви хешове, по приблизително същия начин, по който се организират индексите в базата данни (B + дърво, например) и скоростта на търсене ще бъде напълно приемлива (както частични, така и пълни съвпадения), като бонус - сортирано обхождане.

Всъщност скоростта на търсене сред трилиони стойности е доста висока, какво да кажем за персонализирани речници:)

С броя на позициите в 70 000, дори скучно полуразделение в сортиран списък ще намери желания максимум в 17 повторения. Въпросът е - струва ли си да се изгради градина с всякакви камбани и свирки?

Нещо вечер трудно мисля. За точно търсене са необходими максимум 17 итерации и за постепенно ?