Каков практический способ синхронизации данных в каталоге с базой данных?

Question

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

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

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

Я пытаюсь выполнить эту задачу, используя Ruby Sequel и MySQL, на случай, если это имеет значение.

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

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

Answer 1

С точки зрения общих стратегий,

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

Обратите внимание, что будет и не будет медленным: вставка базы данных - самая быстрая операция с базой данных. Ваша самая медленная операция, вероятно, будет чтение метаданных файловой системы MP3. Отдельные вызовы в файловую систему или базу данных намного дороже, чем операции над множествами (получите список файлов). В частности, операция удаления, которая проверяет сотни строк на наличие файла, будет довольно медленной.

Стратегия 2. Создание промежуточной таблицы в базе данных для сравнения. Ваш скрипт читает все mp3-файлы и вставляет их в промежуточную таблицу, которая является пустой копией mp3-таблицы. Затем вы присоединяетесь к реальной таблице, чтобы определить ходы, удаления, добавления.

Стратегия 3: просто замените всю таблицу базы данных. Я подозреваю, что медленной частью этой операции будет чтение метаданных mp3, а не операции с базой данных. Так как ваш процесс в любом случае читает все метаданные mp3, чтобы идентифицировать изменения, просто заменяйте всю базу данных sql при каждом обновлении.

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

Стратегия 4: В зависимости от версии вашей ОС, извлечение метаданных mp3 может быть медленным (а может и нет?) Простые SQL-запросы могут идентифицировать файлы, которые необходимо обновить (прочитать данные в формате mp3), удалить из таблицы или вставить.

Другие подходы: обратите внимание, что многие операционные системы и продукты уже разрешают запросы в стиле базы данных к данным, о которых вы говорите. Служба индексации MS, например.

Answer 2

Вы, вероятно, могли бы справиться с этим с помощью 2 запланированных скриптов cron.

Первый сценарий может сканировать каталог и искать файлы с модовой датой, превышающей время последнего сканирования (или основанного на самой новой записи в БД). Когда новый файл найден, скрипт может выполнить вставку.

Вы можете прочитать теги ID3 в формате MP3, чтобы получить большинство метаданных, которые вы ищете, хотя это предполагает, что все ваши файлы содержат эти данные. Необходимо учитывать механизмы резервирования для того, что происходит при отсутствии данных, например, вместо этого использовать имя файла.

Сценарий удаления может работать в обратном порядке. Вам нужно будет сохранить в базе данных поле, содержащее относительный путь к файлу в каталоге. Затем вы можете просмотреть записи базы данных и проверить, существует ли каждый файл. Когда один не найден, вы можете добавить идентификатор в список. После сканирования вы можете выполнить оператор удаления для захваченных идентификаторов.