Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 3 >
Bulgar © (2004-06-21 16:45:00)
Доброго времени суток

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

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

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

jack128 (2004-07-05 11:42:00) [1]
свои прикидки я делал вот по этой статье http://www.ibase.ru/devinfo/calcindex.htm

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

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

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

jack128 (2004-07-05 11:25:00) [4]

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

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

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

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

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

ЮЮ (2004-07-05 09:36:00) [9]
>Про индексы можно сразу забыть ...

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

Курдль (2004-07-05 09:29:00) [10]
Есть еще лучший способ - зашить "список слов и толкований" в .ехе-шник, или в ресурсный файл. Ведь автор ничего не писал про возможность редактирования:

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

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

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

Anatoly Podgoretsky (2004-07-05 07:49:00) [13]
Про индексы можно сразу забыть, посколько типовой поиск будет выглядеть так, слово из 7 букв, где вторая А, а последнея Т

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

kaif (2004-07-05 04:18:00) [15]
Есть еще один вариант. Использовать таблицу в памяти. Типа 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 занимают отдельные файлы.
Можно, конечно и текстовым файлом обойтись. Но уж лучше тогда двумя - один для слов, второй - для дефиниций. А индексированный поиск самому написать с учетом того, какого рода поиск вообще в кроссвордах применяется. Там, возможно, нужны иные решения, чем простой индексный поиск, так как нужно подбирать слова по маскам типа А***А***М. И не факт, что обычные индексы в этом смысле смогут служить каким-то подспорьем...
Пожалуй, я бы заложился все же на текстовый файл. По крайней мере там можно было бы проявить фантазию и, возможно, ускорить поиск нужных слов значительно. А любая база данных даст в конечном итоге в основном прямой перебор и все преимущества индексов в этой задаческорее всего использоваться не будут.

Fay (2004-07-05 03:20:00) [16]
2Bulgar © (21.06.04 16:45)
О какой именно "работе тексовым файлом" идёт речь? Далекл не всегда можно обеспечить недостаточное быстродействие.

jack128 (2004-07-04 23:57:00) [17]

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

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

jack128 (2004-07-04 23:11:00) [19]

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

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

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

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »