Перевод по словарю

[rus-us]

Задача:
сделать переводчик с англ. на рус. по словарю
словарь сейчас хранится в текстовых файлах (максимальный файл около 6000 строк. 900кб)
в таком виде:

#ablation 1) хир. удаление 2) геол. снос, размывание пород; таяние ледников#

Как лучше организовать поиск перевода для 1 слова, без учета регистра?

Сейчас я просто загружаю файл через file_get_contents() и регуляркой нахожу нужный кусок текста.
Интерисует самый оптимальный вариант.

 

[nulled-dc]

Как лучше организовать поиск перевода для 1 слова, без учета регистра?

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

1. хранил количество слов в отдельном файле, пусть это будет число t
2. сделал некий коэффициент k = t / 25 - это будет среднее количество слов для одной английской буквы.
3. с целью поиска слова на букву с номером w считывал файл начиная с позиции pos = (w - 1) * k
4. дальше считывал бы либо на строку назад, либо на строку вперед, в зависимости от того, в какую сторону промазал. и так, пока не поймаешь слово.
оптимизировать такой алгоритм можно бесконечно. начиная от таблицы коэффициентов для разных букв алфавита вместо k (в пункте 2), заканчивая более интелектуальной работой пункта 4 (переход не на 1 строку назад/вперед, а сразу на несколько, в зависимости от того как сильно промазал).

еще более быстрый вариант - создать скриптик, который по словарю сделает трехуровневую файловую структуру вида:
/a/
/a/ab/
/a/ab/abricos.txt
/a/ab/absolute.txt
и т.д.
где в текстовых файлах будет перевод. тогда перевод слова будет по обращению к файлу, если нет файла- нет и перевода.

 

[ewg777]

/a/
/a/ab/
/a/ab/abricos.txt
/a/ab/absolute.txt

Явное извращение!
Просто 26 файлов (каждый файл - первая буква).
Или sqlite

 

[nulled-dc]

Явное извращение!
Просто 26 файлов (каждый файл - первая буква).
Или sqlite

Насчет явного извращения не согласен. 26 файлов вместо 1 - быстрее, но все еще очень далеко от оптимальности. И медленное построчное чтение файлов никуда не исчезло. А ведь требуется именно оптимизация по скорости работы и ресурсоемкости, если я правильно понял ТС.

Если у кого вопросы, почему каталога 2 - потому что никогда не помешает возможность лазить по созданной куче файлов из шелла. Лучше 25 каталогов и в каждом максимум 25 подкаталогов с N файлов, чем 25 каталогов, в каждом из которых 25 * N файлов.

 

[serjinio]

перегоняйте однозначно в mysql..сначала немного помучаетесь..потом спасибо скажете....
всего то две таблички...в нете море примеров по поиску в бд....а на многих фришных хостах есть mysql сервер...

 

[venetu]

Какой mysql? Какие файлы? 900кб великолепно влазит в память. Целиком.
В виде
'acronym' => 'акроним',
'apple' => 'яблоко',
и т.д.

И "переводчик" делается через обычный str_replace(array_keys(), array_values()). Втупую и очень быстро. Причем быстро как в плане скорости работы, так и в плане собственно написания.

 

[rus-us]

Я изначально разбил файлы по буквам, и потом просто загоняю файл в строку и регуляркой нахожу совпадение.

preg_match_all('|#apple (.*)#|Uis', $content, $match, PREG_SET_ORDER);

Просто у меня сомнения насчет нагрузки.

А вот mysql меня вполне устроит, если будет выиграш в скорости и уменьшиться нагрузка.
Если таблица будет на 70 000 строк, mysql нормально справится?

venetu
А как насчет массива в 5000-6000 строк(1 файл)
Или 70 000 если полный словарь?

 

[ewg777]

Я изначально разбил файлы по буквам, и потом просто загоняю файл в строку и регуляркой нахожу совпадение.

Просто у меня сомнения насчет нагрузки.

А вот mysql меня вполне устроит, если будет выиграш в скорости и уменьшиться нагрузка.
Если таблица будет на 70 000 строк, mysql нормально справится?

venetu
А как насчет массива в 5000-6000 строк(1 файл)
Или 70 000 если полный словарь?

А как на счёт самому проверить?

Если таблица будет на 70 000 строк, mysql нормально справится?

А если флудить дальше, меня скоро забанят?

 

[nulled-dc]

Какой mysql? Какие файлы? 900кб великолепно влазит в память. Целиком.
В виде
'acronym' => 'акроним',
'apple' => 'яблоко',
и т.д.

И "переводчик" делается через обычный str_replace(array_keys(), array_values()). Втупую и очень быстро. Причем быстро как в плане скорости работы, так и в плане собственно написания.

Уж лучше тогда оставить как и есть, это не оптимизация, а разбазаривание ресурсов. Если у чела будет штук 10 одновременных обращений к этому так сказать "словарю", то это уже не 900 а 9000 Кб.

Не все хорошо что быстро пишется. Иногда лучше сделать большой код, но максимально быстро работающий и минимально потребляющий ресурсы.

Добавлено через 4 минуты

А вот mysql меня вполне устроит, если будет выиграш в скорости и уменьшиться нагрузка.
Если таблица будет на 70 000 строк, mysql нормально справится?

С этого и следовало начинать. Нормально он справится, даже не думай о том чтоб от него отказываться.

 

[venetu]

И в результате для перевода коротенькой статьи в 1000 знаков оно будет делать порядка 150-200 селектов к базе. По-твоему это рациональное использование ресурсов? Или приемлемая скорость работы?

Если у чела будет штук 10 одновременных обращений к этому так сказать "словарю", то это уже не 900 а 9000 Кб.

А вот тут я вообще запутался. Словарь же не модифицируется вроде. Зачем его копировать? Один раз от памяти отожрать 900кб - никто и не пикнет. Даже если 900 метров словарь будет весить, т.е. в тысячу раз больше, чем сейчас - все равно на современных серваках с 4Gb оперативы он все еще влезет в память, и str_replace() нормально отработает. Но в 1000 раз словарь просто так не увеличишь, у него есть объективный предел кол-ва слов. А значит код этот будет работать считай с любым словарем в любом обозримом будущем. И да, это экономичней, чем загонять словарь сначала в мускул, потом мускул в ту же память, и потом дергать по одному слову.

И не забывай, самый ценный ресурс на планете - это ТЫ.