Восстановление целостности данных

0

Я думаю, что это длинный выстрел, но здесь он идет:

Основной вопрос: как команда разработчиков начинает восстанавливать целостность данных на большом поврежденном наборе данных?

Компания, которой я помогаю, имеет огромную систему MySQL/PHP5 с несколькими годами крутых, недействительных данных, неработающими ссылками и т.д. В довершение всего, эти данные ссылаются на данные о нескольких онлайн-сервисах, таких как Google AdWords.

Таким образом, локальный db имеет проблемы, и отношения между локальным и удаленным (например, AdWords) также имеют проблемы, что усугубляет проблему.

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

  • 0
    Вам нужно указать немного больше, что вы подразумеваете под "поврежденным" в этом контексте - вы говорите о неработающих ссылках, а не о физически поврежденных данных, верно? И откуда приходят онлайн-сервисы ...? Как на них ссылаются?
  • 0
    Ссылки на онлайн-сервисы обрабатываются путем сохранения идентификатора онлайн-данных в нашей локальной базе данных. У нас есть строка, которая представляет локальные данные со столбцом, например «Advertiser_Id», в котором хранится идентификатор AdWords объекта. И да, под «поврежденными» я подразумеваю, что это неработающие ссылки и несинхронизированные данные, таким образом «ломая» систему, используя ее. Опять же, используя AdWords в качестве примера, люди использовали онлайн-интерфейс для добавления / удаления / обновления некоторых данных, в результате чего локальная копия стала несинхронизированной.
Теги:
data-integrity

2 ответа

0
Лучший ответ

Большая проблема заключается в определении того, что вы собираетесь делать с данными проблемы:

  • ничего
  • восстанавливать данные, хранящиеся в другом месте и доступные через код
  • вручную восстановить данные
  • удалить его (или, желательно, архивировать)

И для этого вам нужно установить, как данные проблемы влияют на систему/организацию и как разрешение влияет на систему/организацию.

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

Затем это должно позволить вам определить необходимые исправления, определить приоритетность работы и спланировать использование ресурсов. Он также должен позволять вам определять приоритеты, планировать и частично выявлять устранение основных причин.

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

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

Делать записи о применяемых исправлениях и соответствующих нарушениях правил - и анализировать данные для определения горячих точек, где повторная факторизация может привести к увеличению количества поддерживаемых кодов.

0

В зависимости от требований и степени "повреждения", может быть разумно создать новую базу данных и изменить приложение для обновления обоих параллельно.

Данные, которые действительны, могут быть импортированы в новый d/b, а затем последовательная серия выделений может добавить достоверные данные и импортировать их до тех пор, пока усилия не увеличатся до такой степени, когда уже не имеет смысла пытаться восстановить серьезно поврежденные данные. Разумеется, неповрежденная неполная база данных лучше и полезнее, чем коррумпированная база данных - если она повреждена, ее нельзя назвать "полной".

Ещё вопросы

Сообщество Overcoder
Наверх
Меню