Как хранить данные от парсера

[metrod]

В общем вопрос такой - есть много информации (десятки Мб), которая хранится в xml файлах. Инфа о фильмах (описание, актеры, реж, длина), альбомах (название, количество треков, издатель), статьи и т.д. То есть информация разная от разных парсеров. Все это свалено в папки в виде xml-файлов (1 файл на 1 фильм, диск, статью).

Вот как лучше организовать хранение всей этой информации? Чтобы при случае было удобно ею пользоваться не только мне, но и другим?

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

 

[swer]

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

 

[StDutch]

Разнообразные данные обычно продаются в виде CSV файлов. Как вариант, иногда предлагают дампы mysql либо XLS (формат MS Excel).

Если XML файлы валидны и имеют одинаковую структуру, то набросай XSLT и перегони в CSV, это самый простой способ.

Что касается формата для собственных нужд: ты ничего не сказал про предполагаемые задачи, в которых могут понадобиться эти данные; вариантов слишком много, чтобы их перечислять. Можно хранить в XML, и использовать BerkeleyDB XML DS, но откровенно это сложный способ. Лично я для десктопных приложений и серверных скриптов с малой нагрузкой использую SQlite.

Если понадобится помощь, welcome в личку.

 

[metrod]

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

Данные эти впринципе для будущих сайтов, но когда они будут сделаны, какова будет структура БД неизвестно. То есть суть в том, как лучше все это устроить для последующей быстрой и простой обработки на PHP. Например, быстро импортировать все в таблицы БД, синонимизировать данные и т.д. и т.п. Поэтому сейчас хранение в БД не возможно.

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

Разнообразные данные обычно продаются в виде CSV файлов. Как вариант, иногда предлагают дампы mysql либо XLS (формат MS Excel).

Если XML файлы валидны и имеют одинаковую структуру, то набросай XSLT и перегони в CSV, это самый простой способ.

Что касается формата для собственных нужд: ты ничего не сказал про предполагаемые задачи, в которых могут понадобиться эти данные; вариантов слишком много, чтобы их перечислять. Можно хранить в XML, и использовать BerkeleyDB XML DS, но откровенно это сложный способ. Лично я для десктопных приложений и серверных скриптов с малой нагрузкой использую SQlite.

Если понадобится помощь, welcome в личку.

CSV действительно хороший вариант. Самому почему-то в голову не пришло Спасибо.

Но появился такой вопрос - допустим есть база статей. Как организовать поиск по ней, по ключевым словам и т.д. Серверные варианты не подходят, ибо есть необходимость давать эту базу в пользование другим. Очевидно, выход - использование десктопных программ. В частности в голову пришло MS Access, но думаю это не идеал. У кого какие мысли на этот счет?

 

[KillDead]

Данные эти впринципе для будущих сайтов, но когда они будут сделаны, какова будет структура БД неизвестно. То есть суть в том, как лучше все это устроить для последующей быстрой и простой обработки на PHP. Например, быстро импортировать все в таблицы БД, синонимизировать данные и т.д. и т.п. Поэтому сейчас хранение в БД не возможно.

Почему же невозможно? . Ведь когда ты записываешь в другой формат ты тоже не знаешь структуру будущего сайта.
Хотя если твой парсер всегда выдаёт разную структуру (что мне кажется не есть хорошо), то тогда бд не подходит. Либо нужно создавать кучи таблиц. Или задача стоит- слить и залить и ничего больше. Просто с бд, особенно с большими объёмами, будет более просто оперировать- легко осуществить поиск, удалить дубли, дискретно работать.

 

[swer]

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