SQL Server - Схема БД производства и Схема БД отчетности.Должны ли они быть одинаковыми?

Question

Недавно мы запустили новую производственную базу данных. Схема этой базы данных оптимизирована для OLTP. Мы также готовимся к внедрению сервера отчетов, который будет использоваться для целей отчетности. Я не уверен, что мы должны просто слепо использовать ту же схему для нашей базы данных отчетов, что и для нашей производственной базы данных, и дублировать данные.

Для тех из вас, кто имел дело с отдельными производственными и отчетными базами данных, вы решили использовать ту же схему базы данных для своей базы данных отчетов или схему, которая более эффективна для отчетности; например, может быть, что-то более денормализованное?

Спасибо за мысли по этому поводу.

Answer 1

У истории действительно две стороны:

• если вы сохраняете схему идентичной, то обновление базы данных отчетов из рабочей среды выполняется командой простого копирования (или MERGE в SQL Server 2008). С другой стороны, отчеты могут быть немного сложнее в написании, и они могут не работать оптимально

• если вы разрабатываете отдельную схему отчетности, вы можете оптимизировать ее для нужд отчетности - тогда создание новых отчетов может быть проще и быстрее, и отчеты должны работать лучше. НО: обновление будет сложнее

Так что все сводится к следующему: вы собираетесь создавать много отчетов? Если это так, я бы порекомендовал разработать специальную схему отчетов, оптимизированную для отчетов.

Или главная проблема - это обновление? Если вы можете определить и реализовать это один раз (например, с помощью SQL Server Integration Services), может, в конце концов это не будет большой проблемой?

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

Answer 2

Для серьезных отчетов обычно создается хранилище данных (которое обычно, по крайней мере, несколько денормализовано, и определенные типы вычислений выполняются при обновлении данных, чтобы сохранить от усреднения значений в 1,3 миллиона записей при запуске отчета. Это для вида отчетности, которая включает в себя много агрегированных данных.

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

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

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

Answer 3

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

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

Answer 4

Все ответы, которые я здесь прочитал, хорошие, я бы просто добавил, что вы делаете это поэтапно, останавливаясь, как только ваши цели по производительности и функциональности достигнуты:

Сохраняйте схему идентичной - это просто требует конкуренции и загружает сервер OLTP

Сохраняйте схему идентичной - но добавляйте новые индексированные представления ИЛИ индексируйте базовые таблицы по-другому

Создайте модель стиля частичного хранилища данных (возможно, не сохраняя историю стиля моментальных снимков или медленно меняющиеся измерения или что-либо особенное, не учитываемое в обычной базе данных) из схемы копирования в другой схеме или базе данных на том же сервере отчетов. Преимущества моделей звездообразной схемы огромны для отчетов, представлений, сплющенных для пользователей, словарей данных и т. Д. В этой модели, если ваша база данных OLTP теряет изменения (например, изменения имени клиента) из-за перезаписей, хранилище данных не фиксирует это. информация (часто это не так важно, если вы остановитесь на этом месте). Фактически вы получаете организацию в стиле хранилища данных только для «текущих» данных. Преимущества сохранения копии исходной схемы на сервере отчетов на этом этапе заключаются в том, что вы можете извлекать исходные данные в исходной форме SQL Server вместо какой-либо промежуточной формы (например, текстовых файлов), не влияя на производственный OLTP, и вы могут перемещать модели данных постепенно, некоторые в виде звезд, некоторые в нормальной форме, и все это не влияет на производство. Через некоторое время вы можете удалить всю или часть копии.

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

Answer 5

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

Answer 6

Проще всего скопировать.

Вы можете добавить некоторые представления к этой схеме для упрощения запросов - для концептуальной денормализации.

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

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