| Вопрос: Рус-яп словарь. Что выбрать для БД? | Добавлено: 23.06.05 10:43 |
Автор вопроса:  Ruslan_x
|
|
Нужна помощь специалиста. Что выбрать для хранения данных?
Ситуация такая Программирую рус-яп. словарь. Уже около 150 тыс. записей и в будущем база будет расти где-то до 500 тыс. записей. В основной таблице 3 поля: ------------------------------------------ ID | рус. слово | яп. слово | произношение ------------------------------------------ 01 | КРОКОДИЛ | иероглифы | WANI ------------------------------------------ 02 | ОРЕЛ | иероглифы | WASHI ------------------------------------------ ..... Есть еще несколько таблиц связанных с основной таблицей через ID записи: ID - автор словарной статьи ID - тематика ID - оригинал на англ. языке ..... Основное требование к базе данных - скорость работы. Пробовал использовать .MDB для хранения всех таблиц. Получается медленно. Пришла в голову мысль попробовать плоский файл с произвольным доступом. В этом файле можно хранить записи. И отдельно - файл-индекс. Попробовал считывать данные с плоского файла - скорость очень высокая. Кстати, известные мне коммерческие словари почти все используют для хранения словарных баз какие-то свои специально подготовленные файлы. Итак, какую технологию посоветовали бы уважаемые специалисты? |
| Ответы | Всего ответов: 52 |
|
Номер ответа: 1 Автор ответа:  Sharp Лидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #1 | Добавлено: 23.06.05 11:28 |
|
Основное требование к базе данных - скорость работы MySQL
|
||
|
Номер ответа: 2 Автор ответа: Ruslan_x Вопросов: 7 Ответов: 41 |
Профиль | | #2 | Добавлено: 23.06.05 12:14 |
Спасибо за ответ. Кратко и по существу. 
С MySQL, правда, раньше не сталкивался. Впрочем, всему можно научиться. Пойду в инет - узнавать, как работать на стыке VB.NET и MySQL. |
||
|
Номер ответа: 3 Автор ответа: Ruslan_xВопросов: 7 Ответов: 41 |
Профиль | | #3 | Добавлено: 23.06.05 12:58 |
| Сразу вопрос вдогонку - а нужно ли для работы программы инсталлировать MySQL Server? | ||
|
Номер ответа: 4 Автор ответа: ViktorZ ICQ: 271202919 Вопросов: 56 Ответов: 837 |
Профиль | | #4 | Добавлено: 23.06.05 13:31 |
| Нет это другая СУБд. MySQL и MSsql разные вещи. Нужно инсталировать Mysql. | ||
|
Номер ответа: 5 Автор ответа: Ruslan_xВопросов: 7 Ответов: 41 |
Профиль | | #5 | Добавлено: 23.06.05 19:42 |
|
Вот натолкнулся в инете на альтернативную точку зрения...
http://www.linux.org.ru/view-message.jsp?msgid=274360&scroll=group&back=view-group.jsp%3Fgroup%3D6 ---------------------------- IMHO делать SQL-ные словари -- это расточительство системных ресурсов. если учесть, что односторонний словарь -- это, грубо говоря, одна таблица из двух колонок, первая из которых ключ, а вторая -- статья, а еще к нему нужно несколько индексов (для прямого поиска, для нечеткого, для поиска по звучанию, для поиска по контенту и пр) -- то SQL здесь становится черезчур уж излишним инструментом. к томуже -- словарь -- это вещь массового использования, и разделение на клиент/сервер здесь желательно сделать лишь условным, чтобы в продукт был пригоден к использованию и в однопользовательском варианте. > А чем плохо иметь базы в MySQL? А тем, что надо иметь лишний работающий сервис, со всеми вытекающими последствиями (дыры в системе безопасности, поддерржка, ...), да и ресурсы сервера ... Для таких задач как словарь просто напрашивается простейшая ... DB с ключами с виде сбалансированного двоичного дерева (это делается один раз, зато потом дает очень скоростной доступ). Конечно, ну конечно же, это все можно сделать и по-другому, на крутой базе с бешеными наворотами, потом загибать пальцы... Но смысл не меняется - словарь в SQL - это профанация. Подобные решения - хороший пример того, как НЕ НАДО делать, хотя и возможно. |
||
|
Номер ответа: 6 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #6 | Добавлено: 23.06.05 21:42 |
| Логичное мнение, БД предназначены для частого изменения информации, а словарь довольно постоянен. | ||
|
Номер ответа: 7 Автор ответа: ПавелАдминистратор ICQ: 326066673 Вопросов: 368 Ответов: 5968 |
Web-сайт: Профиль | | #7 | Добавлено: 24.06.05 06:09 |
|
Если для .NET, то однозначно СУБД лучше MS SQL Server не будет.
Хотя конечно столь серьезную СУБД использовать для словаря не совсем правильно. |
||
|
Номер ответа: 8 Автор ответа: Ruslan_xВопросов: 7 Ответов: 41 |
Профиль | | #8 | Добавлено: 24.06.05 06:19 |
| Хорошо, если отвечься от SQL, то есть какие-нибудь другие - более простые - инструменты? | ||
|
Номер ответа: 9 Автор ответа: MorpheusВопросов: 224 Ответов: 3777 |
Web-сайт: Профиль | | #9 | Добавлено: 24.06.05 06:37 |
|
ээээ... а файлы ini (то есть функции типа GetPrivateProfileString ) пробывал? Не знаю как скорость, но большой размер базы гарантирую )
|
||
|
Номер ответа: 10 Автор ответа: Ruslan_xВопросов: 7 Ответов: 41 |
Профиль | | #10 | Добавлено: 24.06.05 10:52 |
| Т.е. вы предлагаете хранить словарную базу на сотни тыс. записей в ini-файле?... | ||
|
Номер ответа: 11 Автор ответа: Ruslan_xВопросов: 7 Ответов: 41 |
Профиль | | #11 | Добавлено: 24.06.05 11:01 |
| Я больше склоняюсь к Random Access File с индексом. Только как это реализовать на практике пока не очень понимаю.... | ||
|
Номер ответа: 12 Автор ответа: CyRax  Разработчик Offline Client ICQ: 204447456 Вопросов: 180 Ответов: 4229 |
Web-сайт: Профиль | | #12 | Добавлено: 24.06.05 11:05 |
|
Попробуй мой класс для работы с DBF-ками.
http://basicproduction.nm.ru/BPDBF.rar Правда без индексирования. |
||
|
Номер ответа: 13 Автор ответа: Ruslan_xВопросов: 7 Ответов: 41 |
Профиль | | #13 | Добавлено: 26.06.05 16:55 |
|
Спасибо всем ответившим.
Взвесив все за и против, я все же остановился на том, чтобы хранить записи в простом файле и отдельно от него хранить индекс. Протестировал эту схему - все очень хорошо работает. ------- При тестировании я хранил индекс в памяти, но это решение не подходит - все индексы сожрут около 30-50 Мб оперативки. Да и загружаться это хозяйство будет долго. Остается одно - хранить индекс на диске в виде файла. Только вот проблема - не знаю как реализовать поиск в индексном файле. Перерыл весь интернет, голова уже опухла, все равно не понимаю, как же все-таки искать в индексе? Все предлагают b-tree search, но я сам не смогу это реализовать, а готовых решений для VB.NET не нашел. Индекс я себе представляю в виде списка key/value, где key - это отдельное слово, а value - ссылка на местоположение словарной статьи (с этим словом) в основном файле. Что-то вроде: ----------------------- абрикос - 0030 арбуз - 0045 ... яблоко - 8794 ----------------------- Учитывая то, что индекс отсортирован по ключевому слову (key), как можно реализовать в нем быстрый поиск? Например binary search? Очень-очень буду признателен за ответ на этот конкретный вопрос. |
||
|
Номер ответа: 14 Автор ответа: MorpheusВопросов: 224 Ответов: 3777 |
Web-сайт: Профиль | | #14 | Добавлено: 26.06.05 17:14 |
|
все индексы сожрут около 30-50 Мб оперативки.
ну это по-божески ещё... А если создать кууучу фалов типа <index>.txt и запихать в архив?
|
||
|
Номер ответа: 15 Автор ответа: SharpЛидер форума ICQ: 216865379 Вопросов: 106 Ответов: 9979 |
Web-сайт: Профиль | | #15 | Добавлено: 26.06.05 17:43 |
|
а готовых решений для VB.NET не нашел. Позор .NET! В C++ это часть STL!
Сделай индексы так: две таблицы типа хэш-статья (для русского и японского), отсортируй по хэшам, затем binary search (aka b-tree) хэшируй запрошенное слово и сравнивай полученный хэш с серединой списка хэшей. Если больше, рассматривай вторую половину, меньше - первую, угадал - радуйся и так, пока не найдешь нужную статью. Нашел - выводишь. А 50-60 метров очень жирно. Пусть 16 байт на хэш, 4 байта на ид статьи, 500 тыс. записей, две таблицы, максимум 20 метров. |
||