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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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