Para ejecutar las bases de datos de SQL Server con éxito, debe estar interesado en el diseño de consultas. Desafortunadamente, la mayoría de la gente no piensa dos veces en el proceso de diseño. Como resultado, cometen errores simples que, aunque son fáciles de evitar, tienen consecuencias de largo alcance.
Para empezar, con consultas mal escritas, no puede garantizar a los usuarios tiempos de recuperación ultrarrápidos. Sus servidores también estarán plagados de problemas desde el primer día. Y en el mundo digital actual, estos son errores que no puede permitirse el lujo de cometer. Pero, ¿cómo evitar cometer estos errores? Estos son algunos consejos sobre cómo hacerlo.
1. Error al revisar su modelo de datos
Su modelo de datos determina cómo los usuarios acceden a los datos. Por lo tanto, piense en su modelo desde el principio. Si no lo hace, tendrá que lidiar con consultas difíciles de manejar y código complicado en el futuro, y ambos tendrán un impacto negativo en el rendimiento. Una manera fácil de averiguar qué consultas se necesitan para acceder a los datos es imprimir su modelo de datos.
O, mejor aún, haga que una herramienta de modelado de datos lo haga por usted. Una herramienta de impresión o modelado le permite ver a lo que se enfrenta. Por lo tanto, se encuentra en una mejor posición para simplificar el código, aumentar el tiempo de codificación, aumentar la precisión y mejorar el rendimiento.
2. No tener en cuenta tu técnica
¿Qué técnica usas? ¿Es la lógica del cursor o la lógica basada en conjuntos? No hay una respuesta fácil a esta pregunta en particular:todo depende del rendimiento que mejor se adapte a tus necesidades. Tome la lógica basada en conjuntos, por ejemplo. Es la opción obvia para el acceso a la base de datos. Después de todo, un servidor SQL está diseñado para ello. Pero, en algunos casos, la lógica del cursor puede superar a la lógica basada. La clave es no usar una técnica cuando la otra sería mejor.
3. No usar técnicas de codificación antiguas
Cuando utiliza técnicas de codificación probadas y probadas, rara vez se encuentra en problemas. Incluso los métodos de codificación que aprendió de SQL Server 2005 pueden resultar útiles hoy. Trate de usar la técnica de manejo de errores TRY…CATCH en su codificación. Los resultados pueden sorprenderle. El uso de Common Table Expressions para jerarquías o el motor de base de datos Common Language Runtime (CLR) también puede dejarlo sorprendido.
Si necesita ayuda para repasar técnicas antiguas, revise un poco y busque algunos artículos en línea. Hay mucho por ahí. Aquí y aquí hay un par de ejemplos de SQL.
4. No aprovechar la revisión por pares
Antes de implementar sus planes de consulta, debe pedirle a otra persona que lo revise. Lo más probable es que otras personas vean lo que te has perdido. Sus revisiones sobre sus índices y el rendimiento de las consultas a menudo lo ayudan a mejorar aún más su código. También podrían aprender una o dos cosas de usted en el proceso y viceversa.
5. Error al probar sus consultas
Los desarrolladores odian tener que probar el código. Primero, es riguroso. Y segundo, el entorno de prueba (hardware y datos) rara vez coincide con el entorno de producción real. Pero las pruebas son una parte necesaria e inevitable de la codificación. Por lo tanto, pruebe a fondo su código y, cuando sea posible, intente imitar el entorno de producción final lo más fielmente posible. Recuerde, sus consultas pueden funcionar bien con unos pocos cientos de registros, pero no con millones en el entorno final.
Conclusión
Las consultas determinan la velocidad y el rendimiento de una base de datos SQL. Por lo tanto, trate de evitar errores comunes, como no revisar su modelo de datos o no considerar qué técnica usar. Otros no utilizan técnicas de codificación antiguas, no aprovechan los mecanismos de revisión por pares y no prueban sus consultas.
