Как эффективно хранить постоянно меняющиеся наборы данных (результаты поиска) для периодических отчетов - PullRequest
Новая
       16

Как эффективно хранить постоянно меняющиеся наборы данных (результаты поиска) для периодических отчетов

0 голосов
/ 19 августа 2010

У меня не получается найти хороший способ хранения набора данных, который постоянно меняется.

Я хочу отслеживать и периодически сообщать о содержимом определенных веб-сайтов.Например, для определенного веб-сайта я хочу отслеживать все доступные документы PDF.Затем я хочу периодически (скажем, ежеквартально) сообщать о количестве документов, номере PDF-версии и различной другой статистике.Кроме того, я хочу отслеживать изменение этих показателей с течением времени.Например, я хочу представить график увеличения количества PDF-документов, предлагаемых на веб-сайте с течением времени.

В основном я представляю длинный список URL-адресов, которые указывают на все PDF-документы на веб-сайте.Эти входные данные поступают с перерывами, но они могут не совпадать с датами, за которые я хочу запустить отчеты.Например, в четвертом квартале 2010 года я могу получить два списка URL-адресов с интервалом в несколько недель.В первом квартале 2011 года я могу получить только один.

У меня возникли проблемы с выяснением того, как эффективно хранить эти входные данные в базе данных некоторых типов, чтобы я мог легко генерировать правильные отчеты.

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

Но, с другой стороны, я боюсь, что может быть довольно сложно поддерживать список уникальныхURL-адреса или документы.Особенно, когда документы добавляются, удаляются, а затем повторно добавляются со временем.Я боюсь, что могу столкнуться со сложностями создания временной базы данных .И мне страшно подумать, что происходит, когда сам документ обновляется, но URL остается неизменным (в этом случае метаданные могут измениться, например, версия PDF, размер файла и т. Д.).

Может кто-нибудь порекомендовать мнехороший способ сохранить эти данные, чтобы я мог создавать отчеты из них?Мне особенно хотелось бы иметь возможность задним числом создавать отчеты.Например, когда я хочу отслеживать новый веб-сайт в первом квартале 2011 года, я хотел бы иметь возможность генерировать отчет и из данных четвертого квартала 2010 года, даже если данные первого квартала 2011 года уже были импортированы.

Заранее спасибо!

Ответы [ 2 ]

1 голос
/ 19 августа 2010

Почему бы не просто одна таблица, называемая чем-то вроде URL_HISTORY: 

URL          VARCHAR  (PK)
START_DATE   DATE     (PK)
END_DATE     DATE
VERSION      VARCHAR

END_DATE должен иметь значение NULL или подходящую фиктивную дату (например, 31 декабря 9999 года), если версия не была заменена; установите END_DATE как последнюю действительную дату, когда версия была заменена, и создайте новую запись для новой версии - например. 

+------------------+-------------+--------------+---------+
|URL               | START_DATE  |  END_DATE    | VERSION |
|..\Harry.pdf      | 01-OCT-2009 |  31-DEC-9999 | 1.1.0   |
|..\SarahJane.pdf  | 01-OCT-2009 |  31-DEC-2009 | 1.1.0   |
|..\SarahJane.pdf  | 01-JAN-2010 |  31-DEC-9999 | 1.1.1   |
+------------------+-------------+--------------+---------+
0 голосов
/ 19 августа 2010

Как насчет использования базы данных документов и вместо сохранения каждого URL-адреса вы сохраняете документ, содержащий коллекцию URL-адресов. На этом этапе всякий раз, когда вы выполняете какой-либо процесс, который выполняет итерацию по всем URL-адресам, вы получаете все документы с существующим временным интервалом или какими-либо квалификациями, которые у вас есть для этого, а затем запускаете все URL-адреса по каждому из документов.

Это также можно эмулировать на сервере sql, просто сериализовав ваш объект в json или xml и сохранив выходные данные в соответствующем столбце.

...