asp.net - mvc5 - render partial asp net core
¿Todos los errores almacenados en el conjunto de registros múltiples de SQL Server? (3)
Contexto
Mi proyecto actual es un sitio público de gran tamaño (2 millones de páginas vistas por día) que ejecuta una mezcla de asp classic y asp.net con un servidor SQL Server 2005. Somos pesados en lecturas, con escrituras ocasionales y prácticamente sin actualizaciones / eliminaciones. Nuestras páginas generalmente se refieren a un solo objeto ''maestro'' con una pila de objetos dependientes (detalles).
Me gusta la idea de devolver todos los datos necesarios para una página en un solo proceso (y absolutamente ningún dato innecesario). Es cierto que esto requiere un proceso dedicado para dichas páginas, pero algunas páginas reciben porcentajes de dos dígitos del tráfico general de nuestro sitio, por lo que vale la pena el tiempo / mantenimiento. Normalmente solo consumimos múltiples registros de nuestro código .net, usando System.Data.SqlClient.SqlDataReader y su método NextResult. Oh, sí, tampoco estoy haciendo actualizaciones / insertos en estos procs (excepto para las variables de la tabla).
La pregunta
Los procs de SQL Server (2005) que devuelven múltiples conjuntos de registros están funcionando bien (en prod) para nosotros hasta ahora, pero estoy un poco preocupado de que los procs multi-recordset sean mi nuevo martillo favorito con el que estoy atacando cada problema (nail). ¿Hay algún error de proceso del servidor sql multi-recordset que deba conocer? ¿Algo que me haga desear no haberlo usado? Específicamente cualquier cosa que afecte la agrupación de conexiones, la utilización de la memoria, etc.
Aquí hay algunos inconvenientes para procs almacenados de registros múltiples:
Ellos hacen que sea más difícil reutilizar el código. Si realiza varias consultas, es probable que pueda volver a utilizar una de esas consultas en otra página.
Hacen más difícil la prueba unitaria. Cada vez que realiza un cambio en una de las consultas, debe probar todos los resultados. Si algo ha cambiado, debe buscar para ver qué consulta ha fallado en la prueba unitaria.
Hacen que sea más difícil ajustar el rendimiento más tarde. Si otro DBA viene detrás de ti para ayudar a mejorar el rendimiento, tienen que cortar más y cortar en dados para descubrir de dónde provienen los problemas. Luego, combine esto con el problema de reutilización del código: si optimizan una consulta, esa consulta se puede usar en varios procesos almacenados diferentes, y luego tienen que ir a arreglarlos todos, lo que hace que se vuelvan a realizar más pruebas de unidades.
Hacen que el manejo de errores sea mucho más difícil. Cuatro de las consultas en el proceso almacenado pueden tener éxito, y el quinto falla. Tienes que planear para eso.
Pueden aumentar los problemas de bloqueo e incurrir en carga en TempDB. Si sus procs almacenados están diseñados de manera tal que necesitan lecturas repetibles, cuantas más consultas ingrese en un proceso almacenado, más tiempo tardará en ejecutarse y más tiempo tardará en devolver esos resultados a su servidor de aplicaciones. . Ese aumento de tiempo significa mayor contención para bloqueos, y más SQL Server tiene que almacenar en TempDB para el control de versiones de filas. Mencionaste que pesas en las lecturas, por lo que este problema en particular no debería ser tan malo para ti, pero debes tenerlo en cuenta antes de reutilizar este martillo en una aplicación de escritura intensiva.
Creo que los procedimientos almacenados de múltiples registros son geniales en algunos casos, y parece que el tuyo es uno de ellos.
Mientras más grande (más tráfico) obtenga su sitio, más importante será que el rendimiento ''adicional'' importe. Si puede combinar llamadas 2-3-4 (y posiblemente nuevas conexiones), a la base de datos en una, podría reducir las visitas de su base de datos entre 4-6-8 millones por día, lo cual es sustancial.
Los uso con moderación, pero cuando lo hago, nunca he tenido un problema (excepto que un programador novato mira el código y no "lo entiende", porque no lo encuentran muy a menudo).
Yo recomendaría tener en invocación en un procedimiento almacenado varias invocaciones internas de procedimientos almacenados que devuelven 1 conjunto de resultados cada uno.
create proc foo
as
execute foobar --returns one result
execute barfoo --returns one result
execute bar --returns one result
De esta manera, cuando los requisitos cambian y solo necesita el 3er y 5to conjunto de resultados, tiene una manera fácil de invocarlos sin agregar nuevos procedimientos almacenados y regenerar su capa de acceso a los datos. Mi aplicación actual devuelve todas las tablas de referencia (por ejemplo, tabla de estados de EE. UU.) Si las quiero o no. Lo peor es cuando necesita obtener una tabla de referencia y el único acceso es a través de un procedimiento almacenado que también ejecuta una consulta cara como uno de sus seis conjuntos de resultados.