На код‑ревью регулярно всплывает одна и та же классическая проблема. Открываешь проект нового разработчика, а там финансовые поля вроде price или balance лежат во float или double. На вопрос о причинах такого выбора обычно следует стандартный ответ: «В ORM всё запускается, копейки сохраняются, на локальной машине работает». О том, что при росте базы двоичная логика округления стандарта IEEE 754 начнет искажать расчеты и терять деньги бизнеса, на ускоренных курсах не рассказывают.

В мире PostgreSQL этот вопрос автоматизирован. Существуют готовые инструменты статического анализа структуры вроде pg‑index‑health. Они интегрируются в процессы CI/CD и блокируют деплой, если кто‑то пытается накатить некорректную миграцию. Для экосистемы MySQL аналогичного легковесного инструмента, проверяющего именно логику и архитектуру схем таблиц (Schema Linting). Моя разработка mysql_guard призвана закрыть эту нишу. Исходный код проекта и подробная двуязычная документация опубликованы на GitHub.

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

Логика инструмента строится на запросах к системному каталогу самого MySQL — базе данных information_schema. В ней СУБД хранит метаданные о структуре всех таблиц. В утилиту заложены три базовые проверки.

1. Финтех‑аудит

Для авто поиска уязвимых финансовых полей, скрипт отправляет в MySQL системный запрос:

select table_name, column_name, data_type from information_schema.columns where table_schema = database() and (column_name like ‘%price%’ or column_name like ‘%balance%’ or column_name like ‘%money%’ or column_name like ‘%cost%’) and data_type in (‘float’, ‘double’, ‘int’);

Если колонка названа как total_price или balance,но разработчик выставил неточный тип данных, утилита подсветит этот баг и укажет на необходимость изменения типа на строгий decimal.

2. Поиск изолированных таблиц

Иногда при спешной разработке, сущности не связываются на уровне самой СУБД через foreign key, а валидация перекладывается на бэк приложения. Это приводит к рискам: при первом же сбое бэка или некорректном удалении записи, база забивается несвязанными мусорными данными.

select t.table_name from information_schema.tables t where t.table_schema = database() and t.table_type = ‘base table’ and t.table_name not in ( select table_name from information_schema.key_column_usage where table_schema = database() and referenced_table_name is not null);

3. Сборка мусора

В процессе тестирования часто создаются временные таблицы (temp_users, debug_table). Их накатывают на базу, а после успешного деплоя забывают удалить. Скрипт сканирует базу и выводит список заброшенных пустых таблиц, в которых после всех тестов осталось ровно 0 строк. Это помогает держать архитектуру в чистоте.

Проект оформлен в виде независимой утилиты, а для запуска проверки достаточно склонировать репозиторий, прописать доступы к своей тестовой базе в блоке DB_CONFIG и выполнить команду python guard.py.

Инструмент можно использовать как чеклист для самопроверки или внедрять отдельным шагом в автоматические проверки перед коммитами. Приветствуются конструктивная критика, пулл‑реквесты и оценки репозитория. Мне будет очень приятно, если вы перейдете на репозиторий и поддержите его звёздочкой.