| |
|
|
| | С таким содержимым:
vid-obekta|Вид объекта||text||0
naselennyy-punkt|Населенный пункт||select|Москва__NEWL__Киев__NEWL__Питер__NEWL__Мурманск__NEWL__Другое|0
tel|Тел||text||0
|
Нужно выбрать все города | |
| |
|
|
| |
|
|
| |
для: OLi
(22.07.2011 в 02:41)
| | | Это полностью содержимое файла или маленький типовой кусочек?
Формат записей не меняется? | |
| |
|
|
| |
|
|
| |
для: Киналь
(22.07.2011 в 11:04)
| | | Это кусок содержимого, формат не меняется, могу добавляться только города (или другие записи) | |
| |
|
|
| |
|
|
| |
для: OLi
(22.07.2011 в 11:58)
| | | >могу добавляться только города (или другие записи)
Хм. Тогда приведите, пожалуйста, подряд несколько кусков, возможно более разнообразных. Чтобы было видно, как именно могут добавляться города, а особенно «другие записи». Только приводите в точности так, как в файле — чтобы было видно также, как куски отделяются друг от друга.
И ещё вопрос: файл большой? Точнее, каков максимальный ожидаемый его размер (в килобайтах)? | |
| |
|
|
| |
|
|
| |
для: OLi
(22.07.2011 в 02:41)
| | | В зависимости от задачи, я бы парсил файл по-разному. Если задача в один момент времени - только найти все города - я бы вообще их нафиг выносил в кэш после первого парсинга. Если задач для работы с этим файлом много - я бы парсил его весь в структуру данных.
В любом случае, парсинг будет состоять из следующих этапов:
1) найти строку, начинающуюся на naselennyy-punkt
2) разсплитить ее по |
3) взять 4 элемент
4) разсплитить его по __NEWL__
5) ...
6) PROFIT! | |
| |
|
|
| |
|
|
| |
для: SHAman
(22.07.2011 в 15:33)
| | | Вместо 2 и 3 можно обрезать строку, просто посчитав символы от начала и от конца. Но меня смущает уточнение автора про «другие данные». И неизвестен размер файла — может, там метров десять и надо вообще на БД переходить) | |
| |
|
|
| |
|
|
| |
для: Киналь
(22.07.2011 в 15:46)
| | | на БД переходить надо в любом случае там где есть поиск
и если вся эта затея с доставанием городов не процесс перехода на БД, то легче застрелиться | |
| |
|
|
| |
|
|
| |
для: Valick
(22.07.2011 в 16:04)
| | | Применение СУБД не всегда оправдано. Вдруг, ТС делает программу для сервера с ограниченными возможностями, где установка сервера СУБД является нереальной задачей. Или памяти не хватает для поддержки СУБД. Или, или, или... слишком много "или" возникает при внедрении СУБД. Так же возможен вариант, когда производительность специализированного решения выше, чем предоставляют СУБД общего назначения. Прежде чем писать "на БД переходить надо в любом случае там где есть поиск" стоит удостовериться в том, что это будет более выгодным решением, чем специализированное решение. | |
| |
|
|
| |
|
|
| |
для: Саня
(22.07.2011 в 16:20)
| | | Так же возможен вариант, когда производительность специализированного решения выше, чем предоставляют СУБД общего назначения.
речь о РНР не забывайте, сможете сделать поиск на РНР быстрее чем поиск по БД... сильно сомневаюсь...
Или, или, или... слишком много "или"
ни одного из "или" ТС не привел
___
а вот грамотная работа с файлами (с учетом нужных блокировок) это реальный гемор и это факт | |
| |
|
|
