В чем лучше хранить данные?
Есть цель сделать морфологический анализатор. Баз базы данных по словам и их описанию тут не обойтись.
Имеется такая база данных в MS Access. У каждого слова есть поле ID, поле, куда записывается само слово и поле, где перечислено описание.
В связи с тем, что БД содержит около нескольких миллионов записей встает вопрос по быстродействию.
Движок, который будет производить анализ слов в тексте, будет написан на Делфи.
Исходя из всего вышесказанного, у меня вопросы:
Какую БД лучше использовать для наиболее быстрой работы? Или может быть залить БД в текстовые файлы?
Как сделать так, чтобы любое слово из такой БД искалось в течении долей секунд?
=============================
Я конечно дилетант в программировании, а особенно под windows, но небольшой опыт, что имеется, подсказывает мне, что тут без индексов в БД не обойтись.
Если переводить на простой язык, то мое видение такое:
-------------------------------------------
а/
аа/
ааа/
аба/
абб/
абв/
аб/
ав/
аг/
б/
...
в/
...
г/
...
...
-------------------------------------------
Базу надо разбить на папки с двумя уровнями вложенности. в каждой из которых будут располагаться часть БД с теми словами, которые имеют начало, схожее с именем папки.
Поделитесь, пожалуйста своими мыслями по этому поводу и помогите советом.
С уважением,
Сергей.
Не самый лучший выбор для системы работы с текстом.
Какую БД лучше использовать для наиболее быстрой работы? Или может быть залить БД в текстовые файлы?
Как сделать так, чтобы любое слово из такой БД искалось в течении долей секунд?
Загрузить в память всю базу (хэш-таблица или дерево). Два миллиона слов не так уж и много (при средней длине слова в 20 букв получим нагрузку на память в 80-100 МБ при использовании Unicode + доп. информация по кажому слову где-то 20-30 МБ добавит).
Загрузить в память всю базу (хэш-таблица или дерево). Два миллиона слов не так уж и много (при средней длине слова в 20 букв получим нагрузку на память в 80-100 МБ при использовании Unicode + доп. информация по кажому слову где-то 20-30 МБ добавит).
Для обработки текста лучше всего, боюсь, подойдут языки вроде Python/Ruby. Тогда это будет по принципу KISS ;).
Если не хочется самому реализовывать деревья и поиск по ним, можно взять Oracle XE (бесплатная, есть некоторые ограничения) и ODAC для доступа к БД. Слова хранить, естественно, в Index-Organized Table.
Добавлено: Конечно, стрельба из пушки по воробьям, но быстро, удобно и эффективно.
Если не хочется самому реализовывать деревья и поиск по ним, можно взять Oracle XE (бесплатная, есть некоторые ограничения) и ODAC для доступа к БД. Слова хранить, естественно, в Index-Organized Table.
Добавлено: Конечно, стрельба из пушки по воробьям, но быстро, удобно и эффективно.
Понятно что и MsSqlServer 2008 Express можно взять :) Ограничения совершенно аналогичные у него. Возможности применительно к этой задаче тоже overkill, но кроме того, есть поддержка хостинга .NET, что может серьезно ускорить обработку данных.
Можно и M$ SQL взять.
[[offtopic]]
Но .NET, имхо, придумана не для того, чтобы ускорить обработку чего-либо, а как раз наоборот, чтобы замедлить чересчур быстрые современные компьютеры.
[[/offtopic]]
Добавлено: А что, в M$ SQL появилась возможность строить дополнительные индексы для IOT?
[[offtopic]]
Но .NET, имхо, придумана не для того, чтобы ускорить обработку чего-либо, а как раз наоборот, чтобы замедлить чересчур быстрые современные компьютеры.
[[/offtopic]]
Добавлено: А что, в M$ SQL появилась возможность строить дополнительные индексы для IOT?
Я в СУБД не сильно разбираюсь, но думаю IOT или обычный индекс тут рояля не сыграет - будет одинакого шустро. Я к тому, что работа кода (ага мегатормозный .NET) с данными в контексте СУБД гораздо шустрее работы кода извне.
Представим, что юзер пишет следующую выборку:
Действия БД в IOT: найти в индексе нужное значение word, достать лежащие рядом id и description.
Во втором случае меньше телодвижений. Мелочь -- а приятно.
Разве топикастер говорил, что будет использовать для разработки .NET? Если же речь идёт о серверной части (триггеры, хранимые процедуры и т.п.), то, думаю, PL/SQL будет не медленнее .NET. Про взаимодействие с СУБД: я предлагал использовать для работы с Oracle компоненты ODAC, которые обеспечивают самую короткую цепочку передачи данных между СУБД и приложением, и .NET, полагаю, не мсожет предложить ничего более эффективного (хотя, сопоставимое -- возможно).
ОК, понятно, IOT это по сути хранение таблицы в виде дерева.
Автор вообще хочет Аксесс использовать для хранения.
Ну тут измерять нужно. Ежели работать с данными то разницы никакой. А если какую логику навернуть, например, что-то нетривиальное со строками сделать, какие-то вычисления дополнительные произвести - тут уже удобнее (да и быстрее) на чем-то более дружественном к программисту, чем PL/SQL.
Я вот как-то регулярные выражения всобачивал в MSSQL ;)
Впрочим задача у автора не такая масштабная, чтобы использовать такие серьезные связки продуктов.
А зачем мне их всобачивать? Они в Oracle уже есть. Это во-первых.
А, во-вторых, если уж мы добрались до необходимости создания расширения функций СУБД, Oracle предоставляет возможность создавать модули на чём угодно, и там есть нормальные удобные механизмы взаимодействия. Microsoft .NET -- очередной стандарт на темноту (есть анекдот такой, потом как-нибудь расскажу).
Добавлено: А что, в M$ SQL появилась возможность строить дополнительные индексы для IOT?
появилось, появилось. Не нужно путать отсутствие терминологии и отсутствие возможности.
Разница между мелкософт и оракле - только в том что один говорит - дай денег, а потом поедешь, второй - везу бесплатно, деньги за вход и выход.
и то и другое - стандарт "на темноту". Разница между Биллом и Томом - только в имени и фамилии.
Я бы так не сказал. В начале эпох, когда не было ничего, появились IBM и Oracle. А кто игру придумал -- тот и правила придумывает. А Microsoft до 2000 года не могла похвастаться наличием своей клиент-серверной СУБД.
Тогда уж между Биллом и Ларри. А разница хотя бы такова, что последний не зациклен на винде, Oracle есть под многие операционные системы.
Я ктому что сейчас год на дворе 2009 и сейчас не обязательно выбирать только только между IBM и Oracle.
Я не говорил, что надо выбирать только между ними. Для задачи топикастера, вполне вероятно, подойдёт и MySQL или вообще что-нибудь встраиваемое типа BerkleyDB. Кстати, обе перечисленных нынче принадлежит Oracle. ;)
зы. 1000-ое сообщение, аднако =)
Сплюнь! А то приглянётся Биллу...
Какое-то не круглое число. Вот будет 1024-е -- тогда и поздравим!