Sql Server Reporting Services vs Informes a través de .NET Application

Question

Mi jefe quiere que cree algunos informes en un futuro próximo y creo que quiere usar SQL Server Reporting Services para implementar los informes. No estoy tan seguro de que esta sea una gran idea, considerando que somos una organización bastante pequeña y no veo que usemos o necesitemos las características que ofrece esta solución, como la configuración de usuarios, grupos y suscripciones.

Aunque no he usado SSRS antes, he visto un seminario web de 3 días y parece que es una de esas cosas que están bien y está bien para situaciones simples pero se vuelve un dolor & demasiado restringido cuando los requisitos volverse más complejo. Me gustaría mucho desplegar los informes como informes locales (.rdlc) en una aplicación .NET porque:

1. yo preferiría procesar & formato a los datos .NET a continuación, SQL. Claro que puedes usar CLR, pero esta ruta parece ser más difícil de mantener y menos ideal que solo procesar datos como lo haría normalmente en una aplicación .NET.
2. Limitaciones en la interfaz de usuario al agregar controles de parámetros, si mal no tengo mucho control sobre el diseño.

Así que supongo que mi pregunta sería en qué situaciones funciona bien SSRS, ¿qué situaciones no funciona bien? ¿Son válidos mis puntos o solo soy un escéptico?

Answer 1

Puede configurar la seguridad para los servicios de informes como en Windows, por lo que si un requerimiento de seguridad cambia, puede modificar la seguridad en RS. Si está incrustado en una aplicación, debe actualizar la aplicación (no lo he hecho así que no conozco todos los pasos) y luego volver a implementar la aplicación para actualizar la seguridad.

Answer 2

Sus puntos son válidos.

Para una aplicación más pequeña, consideraría usar un control ReportViewer en una aplicación ASP.NET si no necesita todas las comodidades. Incluso desde una perspectiva de mantenimiento: solo tienes que administrar una aplicación. Mi equipo está planeando dejar de usar SSRS.

Sé que algunos de los miembros de nuestro equipo hermano tienen informes y estructuras complejas, y necesitan las campanas y silbatos.

Answer 3

Utilizo un poco de ambos, y he encontrado que hay intercambios con cada enfoque.

• Por alguna razón, el diseñador de .rdlc es un poco diferente que el diseñador de .rdl. Puede ser bastante confuso cuando un ejemplo en línea hace suposiciones sobre lo que es su diseñador.
• Generalmente prefiero los informes desplegados en SSRS si intento ser independiente del cliente, ya que los informes basados ​​en .rdlc requieren que usted proporcione el cliente.
• Generalmente prefiero informes basados ​​en .rdlc para aplicaciones independientes, especialmente para clientes que no tienen un centro de datos. Estas tienden a ser aplicaciones donde tanto la aplicación como la base de datos están en la máquina del cliente.
• Me gusta LINQ, y me resulta más fácil de usar como fuente de datos para informes basados ​​en .rdlc.
• Tengo una relación amor/odio con informes basados ​​en .rdlc cuando se trata de refactorización. Mantener sus estructuras de datos en una biblioteca separada de sus informes es importante; de lo contrario, cambiar el nombre de una propiedad provocará que la compilación falle a causa del informe, pero la nueva propiedad no estará disponible en la fuente de datos para el informe hasta que compile.
• Controlar el cliente (.informe basado en rdlc) le da una flexibilidad ilimitada en la forma de presentar y recopilar los valores de los parámetros, lo cual es bastante agradable.

En cualquier caso, dudo que haya cualquier enfoque dogmático que debe palo para, aparte de "hacer lo que tiene sentido." Para mí, en la práctica, utilizo informes basados ​​en .rdlc para pequeñas aplicaciones cliente, e implemento informes de nivel empresarial en un servidor SSRS.

¡Buena suerte!

Answer 4

Tus instintos son buenos, sigue usándolos.

Muchas personas caen en la trampa de llevar la lógica empresarial compleja a las herramientas SQL y de generación de informes. El lugar correcto está en el ETL. No se deje intimidar por el término que cubre simples scripts perl ad-hoc para complejos SSIS. Incluso entonces, el 80% del tiempo las personas usarán SSIS para extraer y cargar solo los datos que guardan la transformación para el informe en tiempo de ejecución (¿Por qué estos informes son tan lentos ?!).

Incluso si se ve obligado a proporcionar los datos a través de SSRS, mantenga su capa de transformación separada del informe en la herramienta/idioma de su elección, manteniendo su SQL simple y conciso.

Para una tienda pequeña, aspx está probablemente bien pero tenga esto en cuenta. Obtienes un montón de cosas gratuitas de SSRS con seguridad y exportación para que Excel sea una gran ventaja para tu jefe. Los informes también son un agujero negro de trabajo ocupado. Su primer puñado de informes se multiplican rápidamente para diferentes usuarios y diferentes motivos comerciales y se vuelven inmanejables. Si configura una buena base de SSRS, puede migrar el trabajo a otra persona cuando sea el momento adecuado.

Si está más interesado, le sugiero leer el almacenamiento de datos.

Una cosa más. Tenga en cuenta la ejecución de informes contra datos en vivo. Los informes suelen tener un perfil de rendimiento diferente que las consultas OLTP. OLTP = unos pocos registran un momento en el que las consultas de Informes (DW) alguna vez requieren escaneos completos de tablas y pueden causar problemas de bloqueo si no se configuran correctamente.

Answer 5

Nadie dijo nada acerca de Report Builder 2.0 o 3.0. Es una gran aplicación solo para generar informes sin necesidad de SSRS ni nada. Simplemente enciéndalo y configúrelo para consumir cualquier fuente de datos que tenga disponible y listo. Quiero decir, puedes compilar fácilmente este informe en poco tiempo. Piénsalo.

Definitivamente no necesita otra solución personalizada de .NET para esto.

Getting Started with Report Builder 3.0