Каковы ваши лучшие практики для обеспечения правильности отчетов от SQL?

Question

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

Когда я создаю отчеты, а более конкретно, я разрабатываю SELECT для извлечения агрегированных данных из базы данных OLTP, я беспокоюсь о том, что я ошибаюсь в JOIN или GROUP BY, например, возвращая неверные результаты.

Я пытаюсь использовать некоторые «лучшие практики», чтобы помешать мне для «создания» неправильные номера:

• При создании объединенного набора данных, всегда взрываются этот набор данных без агрегирования и искать какой-либо очевидной ошибки ,
• Экспортировать взорванные данные в Excel и сравнивать SUM(), AVG() и т. Д. С SQL Server и Excel.
• Привлекайте людей, которые будут использовать эту информацию, и попросите провести валидацию (попросите людей помочь определить ошибки на номерах).
• Никогда не разворачивайте эти вещи днем ​​- когда это возможно, попробуйте взглянуть на T-SQL на следующее утро с освеженным умом. У меня было исправлено множество ошибок с помощью этой простой процедуры.

Даже с этими процедурами я всегда беспокоюсь о номерах.

Каковы ваши лучшие методы обеспечения правильности отчетов?

Answer 1

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

Answer 2

• Подписано, в письменной форме

Я обнаружил, что один из лучших методов является то, что как читатель/клиент и разработчики находятся на одной и той же (документально) стр. Таким образом, когда появляются загадочные цифры (и они это делают), я могу указать на спецификацию в письменной форме и сказать: «Вот почему вы видите этот номер. Хотели бы вы, чтобы он отличался?».

• тест, тест, тест

Для серьезно сложных отчетов, мы прошли через тестовые данные вверх и вниз с клиентом, пока все цифры не были правильными, и клиент были удовлетворены.

• Пограничные случаи

Мы обнаружили серьезно сложный случай в нашей системе отчетности, перевернули все вверх дном (на нашей стороне). Что делать, если пользователь создает отчет (например, год-конец 2009 года), вводит данные на новый год, а затем возвращается для создания того же отчета? Данные изменились, но этот отчет не должен. Мышление и работа над этими случаями может сэкономить массу страданий.

Answer 3

Напишите несколько автоматических тестов.

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

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