Стандарты разработки для служб поддержки SQL Server? - PullRequest
1 голос
/ 30 июля 2009

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

Есть ли у кого-нибудь полезные ссылки или рекомендации по этому вопросу?

1 Ответ

2 голосов
/ 30 июля 2009

Я могу говорить только с SSIS, хотя некоторые из них будут применимы и к другим.

Сохраните ваши пакеты как файлы и поместите их в Source Control.

Где возможно, используйте переменные для вещей, которые будут меняться от сервера к серверу или запускаться для запуска.

Используйте файлы конфигурации для сохранения конфигурации для других сред.

При обработке данных, поступающих из внешнего источника, предположим, что они изменят формат без предупреждения (т. Е. Убедитесь, что данные, которые вы ожидаете в каждом столбце, - это данные, которые вы получили!). Ничто не сравнится с помещением электронных писем в поле фамилии ( или, как это случилось с нами однажды в DTS, номер социального страхования в поле, в котором указано, сколько нужно заплатить человеку, конечно, рад, что мы поймали это до того, как кому-то заплатили эту сумму.).

Вещи, которые я видел, включают добавление новых столбцов, удаление столбцов, которые имеют решающее значение для вашего процесса, изменение порядка столбцов (особенно плохо, когда сам файл не имеет имен столбцов), оставляя заголовки столбцов одинаковыми, но изменение данных, которые они содержат (да, как только я получил файл, в котором данные о фамилии были в столбце с именем First_name и наоборот), данные с новыми значениями, которые не соответствуют значениям в вашей системе (я думаю о ищите типовые вещи, такие как медицинские специальности), выведите странные данные, такие как примечания в поле электронной почты, имена в этом формате, фамилия - 'Willams, Jo' first_name - 'hn' (объедините два поля, чтобы получить полное имя - очевидно, их люди, вводящие данные, просто набирали имя, пока им не заканчивались пробелы, и продолжали в следующем поле, независимо от того, где они были в имени!).

Не помещайте неочищенные данные в вашу базу данных.

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

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

Если вы выполняете много подобных импортов в SSIS, создайте шаблон проекта, который имеет все стандартные журналы и очищает его. Намного быстрее начинать с шаблона и приспосабливаться к новым сопоставлениям на основе нового файла, с которым вы работаете, и вносить незначительные изменения в особенности, относящиеся к этому файлу, чем переписывать каждый пакет служб SSIS с нуля.

Хранить метаданные. Рано или поздно вас спросят, как часто это происходило с ошибкой или через какое время после получения файла происходил импорт или даже когда был последний импорт. Все наши пакеты начинаются и заканчиваются задачей сохранения времени начала и окончания в нашей таблице метаданных. Все пути ошибок включают в себя задачу пометить импорт как сбой в наших метаданных. В конце концов вы можете создать систему, которая знает, сколько записей ожидать, и потерпит неудачу, если новый файл значительно отключен. Метаданные также можно использовать для хранения таких вещей, как количество записей, которые могут помочь идентифицировать, когда они отправили частичный файл вместо целого файла, который вы ожидали, и не позволят вам отбросить 300 000 целей продаж, которые они на самом деле все еще хотят.

...