SQL Reporting Используйте хранимую процедуру proc или query/view

Question

Я разработчик программного обеспечения, а не эксперт TSQL или DBA, просто фон. Одно из моих приложений использует выделение представлений SQL для целей отчетности, на этом этапе (может измениться) приложение Windows выполняет представление, и я отображаю данные в таблице/таблице для целей отчетности. Представления становятся все более сложными и медленными, это одна из проблем. Я занимаюсь перепроектизацией приложения для использования веб-интерфейса для отчетности. Но мой вопрос - это лучший подход к отчетам с точки зрения SQL, должны ли мои отчеты основываться на хранимой процедуре или представлениях? Любые другие комментарии или рекомендации по отчетности SQL приветствуются, как я уже говорил, я разработчик программного обеспечения, и я стараюсь избегать работы SQL, но это стало проблемой, и я подумал, что это подходящее время для того, чтобы обострить знания SQL.

Благодарим вас за чтение.

Answer 1

Хранимые процедуры (SP) - лучший выбор, чем представления, но представления намного лучше, чем SQL-запросы, встроенные в отчеты. Я знаю, что вы не упомянули встроенный SQL, но я собираюсь кратко обсудить это, чтобы дать более округлый ответ.

Когда вы вставляете SQL-запрос в отчет (или приложение или что-либо за пределами базы данных), вы предполагаете, что все объекты, на которые делается ссылка, никоим образом не будут меняться. Это, во-первых, большое предположение (и предположения плохие), а во-вторых, ограничение доступа к владельцу базы данных - не может изменить что-либо, потому что это может что-то сломать.

Когда вы используете SP или представление для доступа к базе данных, вы делаете разумное предположение о том, что имя вызываемого объекта (SP или представление) не изменится и что любой набор параметров останется постоянным или наименьшее пребывание совместимо. Оба подхода скрывают логику запроса от вызывающего абонента - логика может быть исправлена ​​и улучшена с течением времени, не затрагивая вызывающего абонента. Вся база данных может быть реорганизована или даже переопределена до тех пор, пока имя открытого объекта (и любых параметров) останется прежним, и вызывающий абонент никогда не узнает.

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

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