Електронен речник в Делфи
Здравейте. Получих задачата да разработя речник на определени термини с описание, с бързо търсене. Като Лингво. Сега речникът е в документ на 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 итерации и за постепенно ?
- Финансов речник
- Щракнете върху Определения _ кликнете превод _ кликнете обяснете _ Какво е click_Online речник
- Електронен портфейл NellPay Wallet - измама - Печелете пари в интернет
- Ефективни пощенски списъци как да удвоите продажбите си с имейл
- Прочетете онлайн електронната книга Капката вода - безплатно и без регистрация!