Я думаю, что это длинный выстрел, но здесь он идет:
Основной вопрос: как команда разработчиков начинает восстанавливать целостность данных на большом поврежденном наборе данных?
Компания, которой я помогаю, имеет огромную систему MySQL/PHP5 с несколькими годами крутых, недействительных данных, неработающими ссылками и т.д. В довершение всего, эти данные ссылаются на данные о нескольких онлайн-сервисах, таких как Google AdWords.
Таким образом, локальный db имеет проблемы, и отношения между локальным и удаленным (например, AdWords) также имеют проблемы, что усугубляет проблему.
Есть ли у кого-нибудь советы, рекомендации или лучшие практики, которые они могут использовать для начала восстановления целостности данных? И поддерживать целостность данных в системе, которая быстро и постоянно добавляется и обновляется?
Большая проблема заключается в определении того, что вы собираетесь делать с данными проблемы:
И для этого вам нужно установить, как данные проблемы влияют на систему/организацию и как разрешение влияет на систему/организацию.
Это ваш первый уровень классификации. Как только вы получите это, вам нужно начать выявлять конкретные проблемы, и из этого вы получите набор семантических правил, определяющих ошибочные шаблоны.
Затем это должно позволить вам определить необходимые исправления, определить приоритетность работы и спланировать использование ресурсов. Он также должен позволять вам определять приоритеты, планировать и частично выявлять устранение основных причин.
Я не уверен, каково ваше определение "огромный", но я бы сделал вывод о том, что это означает, что в нем много программистов, и в этом случае вам, безусловно, необходимо установить стандарты и процедуры для управления целостностью данных продвигаясь вперед, так же, как вы должны делать с эффективностью и безопасностью.
Правила, которые вы определили, являются отправной точкой для непрерывного управления данными, но вы должны подумать о том, как вы собираетесь применять их в будущем: добавление поля временной метки для каждой таблицы/поддержки таблиц, ссылающихся на строки, которые нарушают определенные правила, означает, что вам не нужно обрабатывать все данные каждый раз, когда вы хотите проверить данные - только материал, который изменился с момента последнего проверки - это хорошая идея отслеживать случаи, которые удаляются из списка нарушений, а также которые добавляются.
Делать записи о применяемых исправлениях и соответствующих нарушениях правил - и анализировать данные для определения горячих точек, где повторная факторизация может привести к увеличению количества поддерживаемых кодов.
В зависимости от требований и степени "повреждения", может быть разумно создать новую базу данных и изменить приложение для обновления обоих параллельно.
Данные, которые действительны, могут быть импортированы в новый d/b, а затем последовательная серия выделений может добавить достоверные данные и импортировать их до тех пор, пока усилия не увеличатся до такой степени, когда уже не имеет смысла пытаться восстановить серьезно поврежденные данные. Разумеется, неповрежденная неполная база данных лучше и полезнее, чем коррумпированная база данных - если она повреждена, ее нельзя назвать "полной".