Полное преобразование схемы БД - как проверить переписанные запросы? - PullRequest
Новая
       36

Полное преобразование схемы БД - как проверить переписанные запросы?

4 голосов
/ 21 июля 2011

Наша база данных плохо спроектирована (мы унаследовали ее). Я переработал схему к чему-то полезному и поддерживаемому. Многие таблицы и столбцы были удалены, многие столбцы были перемещены, и большинство таблиц и столбцов были переименованы. Также были изменены некоторые типы данных.

Я извлек все запросы из наших веб-приложений, и мы начали переписывать их. Мы считаем, что наш администратор баз данных может перенести старые данные в новую схему. Чтобы убедиться, что нам нужно протестировать каждый запрос, сравнив старые результаты с новыми.

Как мы можем проверить такую ​​оптовую миграцию? Мне нужно иметь возможность указать параметры и сопоставить старые таблицы / столбцы с новыми таблицами / столбцами. С сотнями запросов это сложная задача. Я мог бы написать что-нибудь сам, но у меня уже есть много требований к моему времени, поэтому использование существующего инструмента предпочтительнее.

Спасибо!

Ответы [ 3 ]

1 голос
/ 22 сентября 2011

Я должен был сделать это ... и это было легко, потому что я переписал все приложение;)

Многие запросы звучат как основные операции, такие как выбор, вставка, обновления не были абстрагированы вфункции - может быть, это может помочь очистить беспорядок перед адаптацией.

Теперь для тестирования:

Вам нужен тестовый скрипт, который будет а) выполнять все ваши запросы б) хранить вывод всех выборокдля сравнения

  1. сделайте резервную копию вашего теста db @ state 0, очистите общий журнал запросов

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

  3. копировать вставить этот журнал, сделать каждый отдельный выбор и добавить к нему «Создать таблицу temptable_xyz» (или, конечно, SELECT в temptable_xyz .. зависит от доступного синтаксиса)

  4. запустить в обеих базах данных, протестировать db @ state 0 и test db @ state 0 после сценария миграции

  5. сравнить

Это следует сделать, если вы можете макМы уверены, что вы использовали каждую функцию в каждом приложении.

GL - ничего лучше, чем улучшение существующих вещей;)

0 голосов
/ 02 августа 2011

Это мой подход:

  1. Восстановить тестовую базу данных, в которой есть данные, выполнить все известные запросы.
  2. Восстановите еще одну тестовую базу данных, запустите все новые запросы.

  3. Создайте сценарий sql, который присоединяется к таблице каждой базы данных и сравнивает результаты. Это можно сделать с помощью information_schema или других системных таблиц (в зависимости от поставщика).

    вставить во временную таблицу выберите (выберите количество (1) из db1..name) , (выберите количество (1) из db2..name) , (Выберите количество (1) из db1.name t1, присоедините db2.name t2 к t1.col1 = t2.col1 и t1.colx = t2.colx) , имя таблицы

Затем можно выполнить запросы, для которых в запросе указано имя таблицы. Это даст вам отправную точку, где искать.

0 голосов
/ 21 июля 2011

Иногда простые решения делают работу.

Если это просто SELECT, вы можете просто поместить новые и старые запросы в текстовые файлы, запустить их с помощью скрипта и отобразить вывод. 

cd newqueries
for queryfile in *; do
    psql -f $queryfile migrateddb > /tmp/newresult
    psql -f ../oldqueries/$queryfile olddb > /tmp/oldresult

    if ! diff /tmp/oldresult /tmp/newresult; then
        echo "Difference in $queryfile"
        exit 1
    fi
done

Или вы можете написать сравнение результатов на основе модульного теста

...