En este momento creo una conexión de base de datos cuando mi página web se carga por primera vez. Luego proceso la página y ejecuto cualquier consulta contra esa conexión. ¿Es esta la mejor manera de hacerlo o debería crear una conexión de base de datos cada vez que ejecuto una consulta?
ps Tiene más sentido para mí crear 1 conexión y usarla, pero no sé si esto puede causar otros problemas.
Estoy usando C # (ASP.NET) con MSSQL.
Respuestas:
Si crea uno por consulta / transacción, es mucho más fácil administrar "cerrar" las conexiones.
Puedo ver por qué el sentido común dicta que debe abrir uno y usarlo en todo momento, pero se encontrará con problemas con conexiones caídas y subprocesos múltiples. Por lo tanto, su próximo paso será abrir un grupo, digamos de 50, conexiones y mantenerlas abiertas, distribuyéndolas a diferentes procesos. Y luego descubrirá que esto es exactamente lo que el marco .NET ya hace por usted .
Si abre una conexión cuando la necesita y la desecha cuando haya terminado, eso no cerrará la conexión, simplemente la devolverá al grupo de conexiones para que se vuelva a usar.
Se recomienda crear una conexión por consulta, y en el caso de mostrar datos, la mejor práctica es hacer que la consulta traiga todos los datos necesarios de una vez.
Información de antecedentes:
En .NET, las llamadas SqlConnection.Open()utilizarán de manera transparente de forma transparente la agrupación de conexiones (consulte "Uso de la agrupación de conexiones con SQL Server" en MSDN). Por lo tanto, puede tomar una nueva conexión usando Open()y llamar Close()cuando haya terminado, y .NET hará lo correcto.
Tenga en cuenta que sin una agrupación de conexiones, una conexión por consulta sería una muy mala idea porque crear conexiones de bases de datos reales puede ser muy costoso (autenticación, sobrecarga de red, etc.), y el número de conexiones abiertas simultáneas suele ser muy limitado.
SqlConnection.Open()siempre utilizarán de manera transparente la agrupación de conexiones. Por lo tanto, la diferencia entre "abrir una conexión" y "recuperar una conexión desde un grupo" no existe. Mi malentendido. Me tomé la libertad de editar una pequeña explicación de la pregunta y retomé la votación.
Recuerde que todo esto está en el contexto del ecosistema .Net.
Los desarrolladores a veces quieren "optimizar" su código para reutilizar sus objetos de conexión. Dado el contexto de esta pregunta, esto casi siempre es un error.
ADO.Net tiene una característica llamada Connection Pooling . Cuando crea y abre un nuevo objeto de conexión, lo que realmente está haciendo es solicitar una conexión de un grupo. Cuando cierra una conexión, la devuelve al grupo.
Es importante comprender los objetos que usamos directamente en el código: SqlConnection, MySqlConnection, OleDbConnectio, etc., son solo envoltorios alrededor de una conexión subyacente real administrada por ADO.Net, y las conexiones reales de ADO.Net son mucho más "pesadas" y más caras. desde el punto de vista del rendimiento. Son estos objetos subyacentes los que tienen preocupaciones como la autenticación, el tránsito de la red, el cifrado y esas cosas superan con creces la pequeña cantidad de memoria en el objeto que realmente ve en su propio código.
Cuando intentas reutilizar tu objeto de conexión, rompes la capacidad de ADO.Net de administrar eficazmente las conexiones subyacentes importantes. Ganas eficiencia en lo pequeño a expensas de lo mucho más grande.
Reutilizar una conexión a través de una aplicación o solicitud http también puede obligarlo a serializar accidentalmente algo que de otro modo podría ejecutarse en paralelo y convertirse en un cuello de botella de rendimiento. He visto que esto sucede en aplicaciones reales.
En el caso del ejemplo de la página web aquí, donde al menos solo mantiene la conexión pequeña durante la duración de una sola solicitud / respuesta http, podría ganar aún más eficiencia al evaluar qué consultas ejecuta en su canal de solicitudes, e intente obtener reducirlos a la menor cantidad posible de solicitudes a la base de datos (sugerencia: puede enviar más de una consulta en una sola cadena SQL y usar DataReader.NextResult()o verificar diferentes tablas en una DataSetpara moverse entre ellas).
En otras palabras, en lugar de pensar en términos de reutilizar una conexión para una aplicación o solicitud http versus una conexión por consulta, piense en términos de una conexión por cada vez que llame a la base de datos ... cada viaje de ida y vuelta. Luego trate de minimizar la cantidad de conexiones minimizando la cantidad de esos viajes. De esta manera puedes satisfacer ambos objetivos.
Pero ese es solo un tipo de optimización. También se optimiza el tiempo del programador y se obtiene una reutilización efectiva del código. Los desarrolladores no quieren escribir el mismo código repetitivo una y otra vez solo para obtener un objeto de conexión que esté abierto y listo para usar. No solo es tedioso, es una forma de introducir errores en un programa.
Incluso aquí, sin embargo, generalmente es mejor tener una conexión por consulta (o ida y vuelta). Hay otros patrones que puede usar para evitar reescribir el mismo código repetitivo. Aquí hay un ejemplo que me gusta, pero hay muchos otros.