Каковы Ваши лучшие практики для обеспечения правильности отчетов от SQL?
Часть моей работы включает отчеты о создании и данные из SQL Server, который будет использоваться в качестве информации для решения. Большинство данных агрегировано, как материально-технические ресурсы, продажи и стоит общих количеств от отделов и других размеров.
Когда я создаю отчеты, и более конкретно, я разрабатываю ВЫБОРЫ для извлечения агрегированных данных из базы данных OLTP, я волнуюсь о путании СОЕДИНЕНИЯ или GROUP BY, например, возвращая неправильные результаты.
Я пытаюсь использовать некоторые "лучшие практики" для предотвращения меня для "генерации" неправильных чисел:
- При создании набора агрегированных данных всегда взрывайте этот набор данных без агрегирования и ищите любую очевидную ошибку.
- Экспортируйте взорванный набор данных в Excel и сравните СУММУ (), AVG (), и т.д., от SQL Server и Excel.
- Вовлеките людей, которые использовали бы информацию и попросили бы некоторую проверку (попросите, чтобы люди помогли определить ошибки на числах).
- Никогда не развертывайте те вещи днем - если это возможно, пытайтесь смотреть на T-SQL следующим утром с обновленным умом. У меня было исправленное использование многих ошибок этой простой процедуры.
Даже с теми процедурами, я всегда волнуюсь о числах.
Каковы Ваши лучшие практики для обеспечения правильности отчетов?
3 ответа
рассматривали ли вы возможность заполнения таблиц тестовыми данными, которые дают известные результаты, и сравнения результатов вашего запроса с ожидаемыми результатами.
Напишите несколько автоматических тестов.
У нас довольно много отчетов служб отчетов - мы тестируем их с помощью Selenium. Мы используем страницу тестовых данных, чтобы поместить некоторые известные данные в пустую базу данных, затем запустить отчет и убедиться, что числа соответствуют ожидаемым.
Сборки запускаются каждый раз, когда мы регистрируемся, поэтому мы знаем, что не сделали ничего слишком глупого
- Подпись в письменной форме
Я обнаружил, что одна из лучших практик заключается в том, что читатель / клиент и разработчики находятся на одной (задокументированной) странице. Таким образом, когда появляются загадочные числа (а они появляются), я могу указать на спецификацию в письменной форме и сказать: «Вот почему вы видите это число. Хотите, чтобы оно было другим?».
- Тест, тест, тест
Для серьезно сложных отчетов мы просматривали тестовые данные вместе с клиентом, пока все числа не были правильными и клиент не был удовлетворен.
- Edge Cases
Мы обнаружили очень сложный случай в нашей системе отчетности, который перевернул все с ног на голову (с нашей стороны). Что, если пользователь сгенерирует отчет (скажем, на конец 2009 года), введет данные за новый год, а затем вернется, чтобы создать тот же отчет? Данные изменились, но в этом отчете не должно быть. Обдумывание и проработка этих кейсов может сэкономить много душевных страданий.