Как разработчик или администратор баз данных, мы часто сталкиваемся с внутренними приложениями и приложениями сторонних поставщиков. В то время как для внутренних приложений легче улучшить и исправить дизайн базы данных, исправление проблем в приложениях сторонних поставщиков может быть сложным, поскольку у нас нет доступа к их коду. Однако, обычно возможно исправить проблемы с базой данных, если они не затрагивают приложение на фронтенде.
В недавнем случае я столкнулся с приложением стороннего поставщика, в котором отсутствовала компонента на фронтенде, позволяющая обновлять одну из их ключевых таблиц. Поставщик рекомендовал вносить изменения непосредственно в бэкэнд. Однако, таблица не была нормализована и хранила несколько значений групп в одном столбце, что затрудняло удаление или добавление групп по мере необходимости. Поскольку мы не могли изменить код поставщика, я разработал решение для нормализации базы данных без нарушения работы приложения.
Текущая структура и данные
Таблица, на которую падает вопрос, содержала информацию о ресурсах в приложении, включая группы, которым разрешен доступ к каждому ресурсу. Группы были объединены в одном столбце, разделенные символом вертикальной черты (|). В то время как структура таблицы казалась нормальной без данных, стало ясно, что хранение нескольких значений в одном поле и отсутствие обеспечения уникальности вызывает проблемы.
Объяснение изменений в дизайне
Для решения проблем с текущей структурой я предложил следующие изменения:
- Разделить ResourceName на отдельную таблицу с идентификационным столбцом.
- Разделить Groups (уникально) на отдельную таблицу с идентификационным столбцом.
- Создать связующую таблицу для отображения отношения между ресурсами и группами.
- Создать новое представление, которое возвращает информацию в ожидаемом приложением формате.
Реализуя эти изменения, мы можем нормализовать данные, не нарушая работу приложения. Преобразование включает создание трех новых таблиц и представления для замены исходной таблицы.
Последствия изменений
После нормализации таблицы у нас получается три таблицы: Resource, SecurityGroup и ResourceSecurityGroup. Кроме того, мы создаем представление с именем ApplicationResources, которое возвращает те же столбцы и формат данных, что и исходная таблица. Целью было сделать эти изменения незаметными для приложения на фронтенде, чтобы оно не заметило никаких различий или не перестало работать.
Однако, важно отметить, что эти изменения могут незначительно повлиять на производительность. Ранее группы были объединены вместе, не требуя дополнительной обработки. Но теперь, в представлении базы данных, информацию нужно объединять каждый раз, что приводит к небольшому снижению производительности.
Заключение
Нормализация денормализованных таблиц в SQL Server может быть сложной задачей, особенно при работе с приложениями сторонних поставщиков. Тщательно разрабатывая новые структуры таблиц, создавая связующие таблицы и реализуя представления, мы можем достичь более управляемой и нормализованной базы данных, не нарушая работу приложения на фронтенде.
Хотя эти изменения могут повлиять на производительность, они предоставляют более организованное и масштабируемое решение для управления данными. В случаях, когда требуется возможность записи, можно реализовать дополнительные шаги, такие как триггеры, чтобы гарантировать правильное хранение данных в нормализованных таблицах.
В целом, нормализация денормализованных таблиц является ценным методом для улучшения дизайна базы данных и обеспечения целостности данных.