Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.08.01;
Скачать: CL | DM;

Вниз

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

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


 
Anatoly Podgoretsky ©   (2004-07-05 07:49) [30]

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


 
Danilka ©   (2004-07-05 09:18) [31]

[30] Anatoly Podgoretsky ©   (05.07.04 07:49)
доп.поле "длинна слова" и индекс по нему все-таки поможет.


 
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 - для этой задачи будет решением близким к оптимальному (простота, отличная скорость, не нужно ничего в дистрибутив...)


 
Курдль ©   (2004-07-05 09:29) [33]

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

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


 
ЮЮ ©   (2004-07-05 09:36) [34]

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

А при такой структуре
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)


 
Polevi ©   (2004-07-05 09:44) [35]

> [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 разных букв.
Ты представляешь себе вложенность индекса при таких условиях?


 
Anatoly Podgoretsky ©   (2004-07-05 10:37) [38]

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


 
jack128 ©   (2004-07-05 11:25) [39]


> 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]

jack128 ©   (05.07.04 11:25) [39]
>вложенность - это синоним глубины?
Ну, типа того.


 
jack128 ©   (2004-07-05 11:41) [41]


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


 
jack128 ©   (2004-07-05 11:42) [42]

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



Страницы: 1 2 вся ветка

Текущий архив: 2004.08.01;
Скачать: CL | DM;

Наверх




Память: 0.59 MB
Время: 0.063 c
4-1087569763
Andy
2004-06-18 18:42
2004.08.01
Как выдернуть настройки из Explorer а?


4-1081058150
test1
2004-04-04 09:55
2004.08.01
Как программно обновить список установленного оборудования ?


1-1090223846
DDDeN
2004-07-19 11:57
2004.08.01
Сложение даты/времени


3-1089203075
Fast
2004-07-07 16:24
2004.08.01
как поймать момент когда DBGrid переходит в режим редактирования


3-1089000280
Алексей Петухов
2004-07-05 08:04
2004.08.01
Кодировка