Советы по рефакторингу устаревшей схемы базы данных [закрыто]
https://stackoverflow.com/questions/104380
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Застрять на устаревшей схеме базы данных, которая больше не отражает вашу модель данных, - это кошмар каждого разработчика.Тем не менее, несмотря на все разговоры о рефакторинге кода для обеспечения ремонтопригодности, я не так уж много слышал о рефакторинге устаревших схем баз данных.
Каковы несколько советов о том, как перейти к лучшей схеме, не нарушая весь код, который опирается на старую?Я предложу конкретную проблему, с которой столкнулся, чтобы проиллюстрировать свою точку зрения, но не стесняйтесь давать советы по другим методам, которые оказались полезными - они, вероятно, тоже пригодятся.
Мой пример:
Моя компания получает и отгружает продукцию.Теперь с поступлением продукта и отгрузкой продукта связаны некоторые очень разные данные, поэтому разработчики исходной базы данных создали отдельную таблицу для поступлений и для отгрузок.
За год работы с этой системой я пришел к осознанию того, что текущая схема не имеет ни малейшего смысла.В конце концов, и получение, и отгрузка - это, по сути, транзакция, каждая из них предполагает изменение количества товара, по сути, отличается только знак + / -.Действительно, нам часто приходится находить общую величину изменений в продукте за определенный период времени, а это задача, для решения которой данный дизайн совершенно неразрешим.
Очевидно, что подходящей конструкцией было бы иметь единую таблицу транзакций, идентификатор которой является внешним ключом либо таблицы ReceiptInfo, либо таблицы ShipmentInfo.К сожалению, неправильная схема уже несколько лет находится в производстве и содержит сотни хранимых процедур и тысячи строк кода, списанных с нее.Как же тогда я могу перевести схему на корректную работу?
Решение
Вот целый каталог рефакторингов баз данных:
Другие советы
Это очень сложная вещь, с которой можно справиться;Несколькими быстрыми вариантами после рефакторинга базы данных являются:
Эта книга (Рефакторинг баз данных) это было Божьей милостью для меня, когда я имел дело с устаревшими схемами баз данных, в том числе когда мне приходилось сталкиваться с почти точно такой же проблемой для нашей базы данных инвентаризации.
Кроме того, наличие системы для отслеживания изменений в схеме базы данных (например, серии сценариев изменения, которые хранятся в репозитории системы управления версиями) очень помогает в определении зависимостей кода от базы данных.
Хранимые процедуры и представления здесь - ваши друзья.Даже если система их не использует, измените ее, чтобы использовать их, а затем реорганизуйте базу данных под ними.
Затем ваши квитанции и отправления становятся просмотренными.
Будьте осторожны, поступления и отгрузки - это на самом деле две совершенно разные вещи в большинстве систем, с которыми я работал.Поступления связаны с поставщиками, в то время как отгрузки связаны с клиентами (или с местоположениями заказчика/отгрузки).На уровне инвентаризации они часто представлены одинаково.
Ограничен ли весь доступ к данным хранимыми процедурами?Если нет, то задача может оказаться практически невыполнимой.Если это так, вам просто нужно убедиться, что ваши сценарии переноса данных хорошо работают при переходе от старой схемы к новой, а затем убедиться, что ваши хранимые процедуры учитывают все входные и выходные данные.
Надеюсь, ни у кого из них нет запросов "выбрать *".Если они это сделают, используйте 'sp_help tablename', чтобы получить полный список столбцов, скопируйте его и замените каждый * полным списком столбцов, просто чтобы убедиться, что вы не нарушаете клиентский код.
Я бы рекомендовал вносить изменения постепенно и проводить много интеграционных тестов.Трудно провести значительную реконструкцию, не внеся нескольких ошибок.
Первое, что нужно сделать, это создать схему таблицы.Я уже делал это для устаревшей базы данных с помощью Enterprise Architect.Вы можете выбрать базу данных, и она создаст вам все таблицы / поля.Затем вам нужно будет разделить все по категориям.Например, все ваши продукты принимаются и отправляются вместе, клиентские материалы относятся к другой категории.Как только все прояснится, вы сможете провести рефакторинг поля, создав новую таблицу, новый релиз и новые поля.Конечно, это потребует больших изменений, если доступ ко всему будет осуществляться без хранимой процедуры.
Я не думаю, что очевидно, что идентификатор таблицы транзакций должен быть внешним ключом либо для ReceiptInfo, либо для ShipmentInfo.Думай наоборот.В объектно-ориентированной модели у вас должна быть таблица транзакций, а ReceiptInfo или ShipmentInfo должны иметь внешний ключ к таблице транзакций.Если вам повезет, в коде будет только 1 или 2 пункта, в которых делаются новые записи в ReceiptInfo или ShipmentInfo.Там вы должны добавить код, в котором вы добавляете запись в таблицу транзакций, а после этого создаете запись в ReceiptInfo или ShipmentInfo с внешним ключом к транзакции.
Иногда вы можете создавать новые таблицы с улучшенной структурой, а затем создавать представления с именами ваших старых таблиц, но на основе данных в новых таблицах.Таким образом, ваш код не ломается, пока вы начинаете переходить к лучшей структуре.Однако будьте осторожны с этим, поскольку иногда вы переходите от нереляционной таблицы к реляционной структуре, где у вас есть несколько записей, в то время как код будет ожидать только одну.Это особенно верно, если у вас есть разработчики, которые используют подзапросы.
Затем, когда каждая вещь будет изменена, она переместится из представлений в реальную таблицу.В конце концов, вы можете отказаться от просмотра.Это, по крайней мере, позволяет вам работать постепенно, чтобы все работало по мере перемещения материалов, но начните исправлять вещи, чтобы использовать лучший дизайн.
