Альтернатива базе данных

← →
Bulgar © (2004-06-21 16:45) [0]

Доброго времени суток

Я пишу программу для автоматического составления кроссвордов. В программе будет большая база данных слов (150000 слов + толкования + ...), но желательно обойтись без использования СУБД. Как альтернатива предполагается использовать обычный текстовый файл. Вопрос в том как обеспечить достаточное быстродействие при работе тексовым файлом. Просьба подсказать какие-нибудь ссылки или книжки, которые могли бы в этом помочь.

Возможно есть другие альтернативы БД ?

Заранее благодарен

← →
SergP © (2004-06-21 16:49) [1]

А какие у тебя причины для отказа от БД?

← →
Bulgar © (2004-06-21 16:52) [2]

Причины в том, что программка должна быть максисально простой, а база данных - это + Сервер

← →
Ega23 © (2004-06-21 16:58) [3]

Гм, а где ты 150000 слов возьмёшь?

← →
bushmen © (2004-06-21 16:58) [4]

>а база данных - это + Сервер

Ты не прав, БД может состоять из 1 файла

← →
HSolo © (2004-06-21 17:00) [5]

>база данных - это + Сервер
Совсем не обязательно. Например, для dBase есть куча библиотек доступа, к-рые встраиваются в exe-шник, и для работы ничего не надо, только exe-шник + сама база.
Посмотрите здесь: http://www.kylecordes.com/bag/index.html

← →
SergP © (2004-06-21 17:02) [6]

> [2] Bulgar © (21.06.04 16:52)
> Причины в том, что программка должна быть максисально простой,
> а база данных - это + Сервер

А если юзать БД Access?

← →
bushmen © (2004-06-21 17:30) [7]

>А если юзать БД Access?

Надо с собой таскать пакет установки для Jet

← →
Bulgar © (2004-07-04 01:58) [8]

> Гм, а где ты 150000 слов возьмёшь?

Уже есть

← →
Bulgar © (2004-07-04 02:00) [9]

> Ты не прав, БД может состоять из 1 файла

Как это организовать (хотя бы в общих чертах) ?

← →
SergP © (2004-07-04 09:26) [10]

> [7] bushmen © (21.06.04 17:30)
> >А если юзать БД Access?
>
> Надо с собой таскать пакет установки для Jet

Дык Jet стоит на любом компе, где стоит винда и оффис... Зачем его с собой таскать?

← →
Anatoly Podgoretsky © (2004-07-04 10:39) [11]

Jet не стоит на любом компе, где стоит винда и оффис!!!
За подробностями к Микрософт.
Ну или пролистать архивы форума на предмет стонов, сделал базу а она не работает.

← →
YurikGL © (2004-07-04 10:55) [12]

> Anatoly Podgoretsky © (04.07.04 10:39) [11]

Из личного опыта, - никогда не возникало проблем при распространении БДaccess+Ado. Всегда все работало, нужный jet был.
Не скажу, что устанавливал на сотни компов, но десятки наберутся.

← →
SergP © (2004-07-04 12:04) [13]

> [11] Anatoly Podgoretsky © (04.07.04 10:39)
> Jet не стоит на любом компе, где стоит винда и оффис!!!

Ну не знаю... Мне еще не встречались компы, где бы не был установлен Jet. Он был даже на тех компах, где не установлен Access.

← →
Anatoly Podgoretsky © (2004-07-04 12:48) [14]

Я же предложил прочитать данный форум

← →
Sergey Masloff (2004-07-04 13:32) [15]

Исходный пост был про быстродействие. В принципе, никаких проблем с быстродействием при использовании прот\сто текстового файла не будет.

← →
DrPass © (2004-07-04 14:32) [16]

> Ну не знаю... Мне еще не встречались компы, где бы не был
> установлен Jet. Он был даже на тех компах, где не установлен
> Access.

Windows 95 или первая редакция Win98, Windows NT4.0

← →
sniknik © (2004-07-04 14:33) [17]

> Мне еще не встречались компы, где бы не был установлен Jet.
как минимум 4 случая неустановки. (все варианты "чистая" винда, без дополнительных установок)
windows 95 (+ нет DCOM/ADO), windows 98 корпоративная установка (вариант описан на мелкософте, тоже не установлен DCOM), windows NT 4SP (SP выше возможно и входит в какой нибудь), windows XP хомепейдж (стоит по умолчанию DCOM 2,7 в который Jet не включен, и тут есть неопределенность втречались установки как в таком варианте так и с Jet, информации о различиях установок, аналогично 98му (корпоративность/особая поставка) не находил)
не встречались, просто вам везло.

как вариант ClientDataSet фомат hml/cds, можно включить в программу, или ADODataSet pfADTG/pfXML (jet не нужен только ADO вариантов присутствия больше)

← →
Mim1 © (2004-07-04 18:38) [18]

Думается тут неплохо подойдет firebird embedded.

← →
Sergey Masloff (2004-07-04 19:23) [19]

Mim1 © (04.07.04 18:38) [18]
>Думается тут неплохо подойдет firebird embedded.
Ага. Еще Oracle Personal :-)
Да для такой задачи простого файла хватит выше крыши. ИМХО.

← →
Mim1 © (2004-07-04 22:22) [20]

> [19] Sergey Masloff (04.07.04 19:23)

Не стоит передергивать. Демагогия у вас не получается.
Для данной задачи мой совет подходит идеально в отличии от вашего (установка, бесплатность, база в одном файле, надежность (относительная ессно.))
Я это советовал в свете раглагольствований о джетах.
Или вы один из преславутых орклофилов? Есть такие "Нет СУБД кроме оракла и файрберд вестник его". Тупо.

← →
Sergey Masloff (2004-07-04 22:39) [21]

Mim1 © (04.07.04 22:22) [20]
>Не стоит передергивать. Демагогия у вас не получается.
Знаю. Специально же ж...
>Для данной задачи мой совет подходит идеально
Мой (с простым файлом) подходит еще идеальнее. И в плане установки и бесплатности да и по скорости работы тоже. Все же IB какой бы не был Embedded а остается серьезной СУБД со своими безусловными достоинствами и столь же безусловным оверхэдом в рамках данной задачи.

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

← →
Polevi © (2004-07-04 22:44) [22]

xml файл + msxml3 parser

← →
Sergey Masloff (2004-07-04 22:57) [23]

Polevi © (04.07.04 22:44) [22]
А зачем XML? Насколько я понимаю никакой иерархии там (в задаче) нет. Так, для соответствия веяниям? ;-)
Нет, сделать конечно можно. А смысл?

← →
jack128 © (2004-07-04 23:11) [24]

> Так, для соответствия веяниям?
для соответствия веениям - доступ к базе через ADO.NET ;)

А вообще обясните, может я такой тупой - дойти не могу, как вы можете давать советы, что использовать (базу, текстовик или еще что), если автор так и не удосужелся указать что собственно ему мужно от этого хранилища слов. Может ему нужен быстрый поиск по двум последним буквам слова, а может доступ по индексу - как в массиве.. Совершенно разные задачи, требующие разного подхода..

← →
Sergey Masloff (2004-07-04 23:43) [25]

jack128 © (04.07.04 23:11) [24]
>может я такой тупой
да вроде бы нет ;-)
>Совершенно разные задачи, требующие разного подхода..
да какого разного... и на текстовом файле и в xml и в субд все это в полпинка решается.

← →
jack128 © (2004-07-04 23:57) [26]

> да какого разного... и на текстовом файле и в xml и в субд
> все это в полпинка решается.
перебором? Это не наш метод!

← →
Fay (2004-07-05 03:20) [27]

2Bulgar © (21.06.04 16:45)
О какой именно "работе тексовым файлом" идёт речь? Далекл не всегда можно обеспечить недостаточное быстродействие.

← →
kaif © (2004-07-05 04:18) [28]

Есть еще один вариант. Использовать таблицу в памяти. Типа TKbmMemTable или подобную, имеющую, с одной стороны поддержку индексов, а с другой - возможность читать/писать в файл. Так как в данном случае речь идет именно о чтении, то таблицу слов можно посто считать в память целиком. Быстродействие тогда будет колоссальным. Если это TkbmMemTable. Затем, когда кроссворд уже составлен, нужно будет обратиться ко второй таблице с дефинициями. Я бы разделил эти вещи именно для быстродействия. Хотя с точки зрения теории баз данных, это одна таблица...
Возможно, наилучшее, что предлагалось, это использовать dBase. Но с dBase есть ряд проблем. Размер файла будет большим, так как dBase хранит завершающие пробелы, а слова имеют быстро спадающий спектр по длине слов. Так что для хранения в среднем 4-5 буквенных слов придется держать файл длиной 150,000*30 байт, если самое длинное слово состоит из 30 букв, а такие слова в кроссвордах встречаются. Итак, 4.5 Мбайт минимум вместо 750 Кбайт. Так что в предложении Sergey Masloff есть свой резон - IB не хранит концевых пробелов.
Если делать на dBase, я бы сделал 3 отдельных файла:
для слов до 5 символов
для слов до 10 символов
для слов до 50 символов
Но это так, на вскидку. А еще лучше изучить спектр слов и сделать минимальную по общему объему систему из 3-х dBase файлов. Наверняка и алгоритм подбора слов будет работать лучше и быстрее в этом случае.
Определения придется хранить в мемо-полях. Они и так в dBase занимают отдельные файлы.
Можно, конечно и текстовым файлом обойтись. Но уж лучше тогда двумя - один для слов, второй - для дефиниций. А индексированный поиск самому написать с учетом того, какого рода поиск вообще в кроссвордах применяется. Там, возможно, нужны иные решения, чем простой индексный поиск, так как нужно подбирать слова по маскам типа А***А***М. И не факт, что обычные индексы в этом смысле смогут служить каким-то подспорьем...
Пожалуй, я бы заложился все же на текстовый файл. По крайней мере там можно было бы проявить фантазию и, возможно, ускорить поиск нужных слов значительно. А любая база данных даст в конечном итоге в основном прямой перебор и все преимущества индексов в этой задаче скорее всего использоваться не будут.

← →
kaif © (2004-07-05 04:24) [29]

В общем, выбор хранилища определяется самим алгоритмом поиска слов. Если ты придумал какой-то вариант дополнительных полей в таблице, упрощающих поиск слов. и алгоритм на это опирается, то лучшее решение, все же, возможно dBase. Но повторюсь - придется сделать несколько таблиц, на разные длины слов. Возможно, самая странная и быстрая система состояла бы из десятков таблиц:
все трехбуквенные слова (почти все:)
все четырехбуквенные
все пятибуквенные
и так далее
И к каждой свои индексы, на каждую букву.
Ужас, в общем...
Так что алгоритм поиска и выбор хранилища - эт две задачи связаны и надо их решать в комплексе. Мне так кажется...

Про индексы можно сразу забыть, посколько типовой поиск будет выглядеть так, слово из 7 букв, где вторая А, а последнея Т

← →
Sergey_Masloff (2004-07-05 09:26) [32]

jack128 © (04.07.04 23:57) [26]
>перебором? Это не наш метод!
1) см. Anatoly Podgoretsky © (05.07.04 07:49) [30]
2) текстовый файл + RegExp - для этой задачи будет решением близким к оптимальному (простота, отличная скорость, не нужно ничего в дистрибутив...)

Есть еще лучший способ - зашить "список слов и толкований" в .ехе-шник, или в ресурсный файл. Ведь автор ничего не писал про возможность редактирования:

> В программе будет большая база данных слов (150000 слов
> + толкования + ...), но желательно обойтись без использования
> СУБД.

>Про индексы можно сразу забыть ...

А при такой структуре
WORDS
Id: integer
Count: integer

LETTERS
IdWord: integer
Position: integer
Letter: char;

и таком запросе?

SELECT DISTINCT(IdWord)
FROM
LETTERS l
LEFT JOIN WORDS w ON l.IdWord = w.Id
WHERE
(l.Letter = "A") AND (l.Position = 2) AND
(l.Letter = "T") AND (l.Position = 7) AND
(w.Count = 7)

> [23] Sergey Masloff (04.07.04 22:57)
>А зачем XML?
а затем что можно будет пользоваться возможностями парсера, xpath запросы и другие вкусности xml технологий, например xslt преобразования для формирования html отчетов и тд

← →
Sergey_Masloff (2004-07-05 10:18) [36]

Polevi © (05.07.04 09:44) [35]
Ну хтмл отчеты там не особо я думаю нужны ;-)
Я ж не против XML вообще - наоборот. Но считаю для данной задачи RegExp лучше xpath и текстовый файл лучше XML.

← →
Sergey_Masloff (2004-07-05 10:20) [37]

ЮЮ © (05.07.04 09:36) [34]
>WHERE
> (l.Letter = "A")
150000 слов * 6 букв (в среднем)
всего ~ 30 разных букв.
Ты представляешь себе вложенность индекса при таких условиях?

Sergey_Masloff (05.07.04 10:20) [37]
Ну ты пожадничал, в русском языке средняя длина 7 символов, в английском 5

> Sergey_Masloff (05.07.04 09:26)
> jack128 © (04.07.04 23:57) [26]
> >перебором? Это не наш метод!
> 1) см. Anatoly Podgoretsky © (05.07.04 07:49) [30]

> Anatoly Podgoretsky © (05.07.04 07:49)
> типовой поиск будет выглядеть так, слово из 7 букв, где вторая А, а последнея
Вот это все таки должен был сказать автор вопроса, а не Анатолий ;-)

> Ты представляешь себе вложенность индекса при таких условиях?
вложенность - это синоним глубины? (Depth - в терминах gstat/IB)

← →
Sergey_Masloff (2004-07-05 11:28) [40]

> Ну, типа того
тогда я снова не понимаю :-) Кол-во записей в варианте ЮЮ = 7 * 150000 = 1050000 - размер ключа 12 байт. При таких параметрах на том же IB в базе со страницей 4К глубина гарантированно <= 3

свои прикидки я делал вот по этой статье http://www.ibase.ru/devinfo/calcindex.htm

Альтернатива базе данных Найти похожие ветки