Статический анализ структуры базы данных (часть 1) |
||
МЕНЮ Главная страница Поиск Регистрация на сайте Помощь проекту Архив новостей ТЕМЫ Новости ИИ Голосовой помощник Разработка ИИГородские сумасшедшие ИИ в медицине ИИ проекты Искусственные нейросети Искусственный интеллект Слежка за людьми Угроза ИИ ИИ теория Внедрение ИИКомпьютерные науки Машинное обуч. (Ошибки) Машинное обучение Машинный перевод Нейронные сети начинающим Психология ИИ Реализация ИИ Реализация нейросетей Создание беспилотных авто Трезво про ИИ Философия ИИ Big data Работа разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика
Генетические алгоритмы Капсульные нейросети Основы нейронных сетей Распознавание лиц Распознавание образов Распознавание речи Творчество ИИ Техническое зрение Чат-боты Авторизация |
2024-04-10 07:56 Статический анализ структуры базы данных — это процесс выявления ошибок, нерекомендуемых практик и потенциальных проблем в базе данных только на основе структуры, типов данных, свойств объектов. Статический анализ структуры не задействует ни пользовательские данные, ни статистику по таким данным. Рассмотрим подробнее статический анализ структуры базы данных — что это, какие задачи решает, как интегрировать статический анализ в CI. Опираясь на данное выше определение мы получаем следующие важные свойства:
Рассмотрим примеры статического анализа на базе PostgreSQL. Для упрощения кода ниже в примерах будем подразумевать, что операции выполняются в схеме Список статей
Проверки свойств и состояния служебных объектов Начнём с самого простого — проверки свойств и состояния служебных объектов. Это больше характеризует текущее состояние базы данных и лишь частично относится к процессу разработки. У пользователя базы данных, под которым будут выполняться проверки, должно быть достаточно прав, в противном случае часть данных будет недоступна или будет возвращаться Состояние validated ограничений (все ли данные соответствуют ограничениям) Некоторые типы ограничений (в настоящее время это ограничение-проверка Важно отметить, что ограничение сразу после создания будет действовать при добавлении или изменении данных и любая из этих эти операции будут прервана, если новые данные не соответствуют ограничению. Однако на уровне базы данных будет установлен признак, что ограничение не было проверено для всех данных, пока оно не будет проверено командой Типовой сценарий:
В некоторых случаях процесс корректировки может затянуться или потеряться между ответственными, либо в процессе разработки появились ограничения с Задача: проверить базу данных на наличие ограничений, у которых "не все данные проверены" с помощью Пример для проверки состояния validated ограничений
Код проверки состония validated ограничений
Состояние последовательностей (много ли осталось до предельного значения) Суррогатные PK, если они не определены как UUID, как правило, заполняются значениями из некоторой последовательности (генератора). Каждая последовательность имеет граничные значения Из-за массовых загрузок данных или изменения обстоятельств после создания последовательности расход значений может возрастать, объем оставшихся доступных для использования значений до достижения границы сокращается, если последовательность не создана цикличной. Применение цикличных последовательностей подходит не для всех типов данных и имеет свои подводные камни. Задача: оценить в процентах объем оставшихся значений в последовательностях, низкое значение это признак возможного скорого исчерпания доступных значений. Задача не сложная, если иметь параметры последовательности и её актуальное значение. Необходимое актуальное значение, с некоторыми оговорками, присутствует в представлении Пример для проверки состония последовательностей
Код проверки состония последовательностей
Индексирование полей, содержащих массив значений (правильный ли тип индекса выбран) PostgreSQL, как и многие другие СУБД, поддерживает создание колонок, которые содержат многомерный массив [5], и широкий набор функций для работы с массивами [6]. Реализация работы с массивами в PostgreSQL лишь частично соответствует стандарту ISO/IEC 9075-15 Многомерные массивы (SQL/MDA) [7, 8]. Если в базе данных используются колонки с массивами часто на них создают индекс для ускорения поиска [9]. Здесь важно учитывать какие операции сравнения с массивами и их элементами будут использоваться. Если будет выполняться сравнение массивов целиком, эффективен будет индекс Второй случай, когда выполняется фильтрация по элементам массива, встречается на практике значительно чаще. Учитывая сказанное выше, целесообразно обратить внимание разработчика на ситуацию, когда для колонки с массивом значений создан индекс Пример для проверки индексирование полей, содержащих массив значений
Код для проверки индексирвоание полей, содержащих массив значений
Продолжение В следующей части рассмотрим проверки Статический анализ структуры базы данных целесообразно проводить в т.ч. в prod окружении, на регулярной основе, завязать результаты проверок на мониторинг. Уверен, что в недалеком будущем это перестанет восприниматься как экзотика и подобные инструменты для проверки будут "из коробки" предоставлять облачные провайдеры баз данных и плагины к IDE. Ссылки [1] https://postgrespro.ru/docs CONSTRAINT NOT VALID [2] https://postgrespro.ru/docs CREATE SEQUENCE [3] https://postgrespro.ru/docs pg_sequences [4] https://postgrespro.ru/docs pg_sequence [5] https://postgrespro.ru/docs arrays [6] https://postgrespro.ru/docs functions array [7] https://postgrespro.ru/docs features [8] https://postgrespro.ru/docs features sql standard [9] https://postgrespro.ru/docs CREATE INDEX [10] https://postgrespro.ru/docs EXPLAIN Рассмотренные выше проверки можно найти в репозитории https://github.com/sdblist/db_verifier Источник: habr.com Комментарии: |
|