Структура проверки целостности базы данных

Question

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

Требования:

• Легко написать новые правила или проверки
• Простота выполнения всех правил, группировка подмножеств правил будет бонусом
• Точная и простая отчетность по правилам, когда они выполняются или после исполнения

Я собираюсь написать что-то подобное сам, но я подумал, что увижу, смогу ли я сначала найти что-нибудь еще там. Я погуглил, но ничего не смог найти.

Некоторые примеры правил:

• Убедитесь, что в дочерней таблице для каждой записи с [Rank] N, что N равно 0, или есть запись с [Rank] N-1. Например. дочерние записи всегда будут иметь монотонно увеличивающиеся ранги от 0 до MAX (Rank) для данного родителя.
• В нашей базе данных используется глобальная система «тип / идентификатор» с единственной таблицей MasterEntity, которая является таблицей заголовков для каждого объекта в системе. Каждый тип сущности принадлежит одной или нескольким конкретным таблицам сущностей, и каждая таблица сущностей допускает только один или несколько конкретных типов. Убедитесь, что все объекты в системе имеют правильные записи в соответствующих таблицах объектов.
• Убедитесь, что все защищаемые типы имеют запись в нашей таблице дескрипторов безопасности

Answer 1

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

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

Мы используем Nagios в качестве решения для мониторинга системы. Все, что он делает, это позволяет вам определять правила, которые проверяются с помощью скрипта - в нашем случае файл .sql, запускаемый интерфейсом командной строки базы данных (sqlplus для Oracle). Скрипты должны возвращать значение pass, fail или warn. Вы можете настроить, как вы будете получать уведомления (почта, пейджинг и т. Д.) И когда (каждый сбой или просто первый раз, когда он терпит неудачу, пока не будет «очищен» в результате успеха), и он отслеживает историю событий. Что касается самих правил, то здесь нет «основы» с точки зрения применения ограничений «укажи и щелкни» - вам нужно будет выразить правило, написав свой собственный sql.

Это большое поле - просто поищите в Google "мониторинг приложений" и найдите продукт, который соответствует вашим потребностям.

Answer 2

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

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

2. Инкапсулируйте всю обработку исключений в отдельные гранулированные хранимые процедуры с согласованным соглашением об именах (т.е. usp_Integrity_XXXX).

3. Создайте основной хранимый процесс (usp_Integrity_Master), который либо вызывает все эти хранимые процессы явно, либо использует динамический SQL с курсором на INFORMATION_SCHEMA, чтобы найти соответствующие процедуры и вызвать их последовательно, регистрируя все результаты. к соответствующей таблице и отправке электронной почты, отчета или чего-либо еще.

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

Answer 3

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

Для этого вам нужна реляционная СУБД, и, увы, такого еще не существует.

Чтобы сделать это в системе SQL, вы можете написать огромное количество кода принудительного применения ограничений и спрятать их в триггерах и т. Д. Если об этом не может быть и речи из-за политики и тому подобного, в настоящее время не существует рабочего решения вашей проблемы.

Остерегайтесь тех, кто ведет вас к объектным решениям, которые не могут быть тесно связаны с самой СУБД. В конце концов, кто-то развернет некоторый код, который обходит ваши правила принудительного применения ограничений вне базы данных, оставляя вас именно там, где вы были, когда решили задать этот вопрос.

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

Согласно теории, все ограничения базы данных могут быть сформулированы как «запрос, результат которого всегда должен быть пустым». Таким образом, такой запрос, например, даст вам что-то вроде «все пары отдельных строк, имеющих одинаковое значение ключа», или, вообще говоря, такой запрос даст вам список «всех неправильных вещей».

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

Answer 4

Почти со всеми из них можно справиться, используя триггеры для расширенных ограничений целостности.

Я предлагаю ознакомиться с Моделированием ролей объектов как способом проектирования реляционных данных с более детальным набором ограничений, включая описанные вами типы проверок.

Answer 5

Я бы рекомендовал BG Benchmark (http://www.bgbenchmark.org). Это тест, используемый для оценки разных хранилищ данных (хранилищ данных как SQL, так и NoSQL). Одной из его уникальных функций является возможность количественно определить количество устаревших данных, которые не предлагают другие тесты или инфраструктура.

В настоящее время BG моделирует данные и действия для поддержки социальной сети. Вы можете определить свои действия, которые соответствуют вашим правилам.

Answer 6

Хорошо, вы могли бы смешать правильный ответ (ограничения и триггеры) с вашим неправильным ответом (проверить после факта), создав вторую идентичную базу данных с ограничениями и затем попытавшись перенести данные. Если новая база данных выдает колебания при попытке вставить, вы обнаружили ошибку. Как только ваша «политическая» проблема решена, вы можете просто перенести все это навсегда.