notifications Notificaciones

Marcar todas como leídas

Ver más

1415 veces ha sido leído este artículo

Cómo escribir mejores sentencias SQL.

Lo lees en 5 Min.

Cover del artículo sobre sentencias SQL

Si te encuentras comenzando en este mundo de la programación es innegable que en algún momento tendrás que trabajar con una base de datos, no importa si te dedicas al desarrollo de sistemas, páginas web, móviles etc...

Las bases de datos están por todas partes. La gran mayoría de las aplicaciones que utilizas en tu día a día trabajan con una base de datos. Este artículo por ejemplo, se encuentra almacenado en una base de datos.

Me atrevo a decir que las bases de datos son el core de nuestras aplicaciones. Si nuestro modelado o las sentencias SQL que utilizamos no son las correctas nuestras aplicaciones tendrán grandes problema de performance y a nadie, le gusta utilizar aplicaciones lentas.

Es por ello que en este artículo listamos un par de puntos, que considero en lo personal, pueden ayudarte a mejorar tus sentencias SQL.

Obtener lo necesario.

Cuando comenzamos a trabajar con las bases de datos existe una sentencia que estaremos utilizando mucho, lo encontraremos en libros, foros, videos etc... y me refieron a

SELECT * 

Con el asterisco (*) nosotros podemos obtener todas las columnas de un registro. Esto funciona muy bien cuando nosotros trabajamos con tablas las cuales poseen pocas columnas, y la cantidad de registros que obtenemos, de igual manera son pocos.

Sin embargo, qué pasa cuando nosotros trabajamos con tablas las cuales poseen muchas columnas, diez, veinte, cincuenta, o más, en esos casos el uso del asterisco ya no se vuelve una muy buena idea, no solo ponemos en riesgos los dato, si no que afectamos al performances de la consulta, ya que para el servidor, no es lo mismo obtener todas las columnas que solo un par de ellas. El servidor necesita más poder de cómputo para poder procesar más columnas, lo cual se traduce en que entre más columnas obtengamos más lentas serán nuestras consultas.

Es por ello que debemos hacer gran énfasis en obtener únicamente los datos que necesitamos. Por ejemplo, si en nuestra aplicación, únicamente mostraremos los nombre de usuarios, entonces en nuestra consulta únicamente debemos de obtener la columna nombre.

SELECT nombre FROM usuarios;

Nuestra regla de oro siempre debe de ser obtener los datos que únicamente necesitamos. Esta regla la debemos de aplicar a todas las consultas, incluidas las sub consultas.

Limita tus resultados.

En la mayoría de los casos nosotros no necesitaremos trabajar con todos los registros de nuestra tabla o inclusive de nuestra consulta; Es por ello que es una muy buena idea limitar la cantidad de registros que obtendremos del servidor, de esta manera nuestra consulta será más rápida.

Las cláusulas que usaremos en MySQL para limitar registros serán : LIMIT y ORDER BY.

Primeros Registros

SELECT nombre, apellido FROM usuarios LIMIT 3;

Últimos registros

SELECT nombre, apellido FROM usuarios ORDER BY id DESC LIMIT 3;

Si estamos utilizando otro gestor de base de datos, como SQL Server, nosotros podemos implementar cláusulas como TOP y ROW NUMBER.

Uso de Llaves

Si queremos que nuestras consultas sean lo más rápidas posibles, lo que debemos de hacer (siempre que podamos) es realizar consultas utilizando campos de llaves como condición.

En MySQL podemos encontrar dos tipos de llaves:

  • Llave Primaria
  • Llave Foránea

Tanto las llaves primarias como la llaves foráneas son mecanismos que utiliza el gestor de base de datos para poder estructurar el almacenamiento de la información, por ende, el uso de estas agiliza la consulta.

Veamos una breve descripción.

La llave primaria es "obligatoria" en todas las tablas. El campo que usemos como llave primaria regularmente será un campo de tipo numérico (positivo), el campo no aceptará nulos ni valores repetidos ? .Esto ya suena muy bien, pero se pone mejor. Los campos de llave primaria son campos indexados, eso quiere decir, que los campos ya poseen una referencia a su registro, algo que sin duda mejora el tiempo consulta significativamente.

Por otro lado las llaves foráneas son referencias de llaves primarias en otras tablas. Nosotros NO podemos almacenar una llave primaria que no exista en un campo de llave foranea, en otras palabras, si el campo de llave foránea posee un valor, entonces existe un registro con esa llave primaria.

Es cien por ciento recomendable que nosotros hagamos las consultas utilizando como condición unas llave primaria, además, siempre que hagamos un join con dos o más tablas siempre debemos de hacer el match mediante las llaves foráneas.

Estrategias de búsquedas.

Es cierto que todas las aplicaciones son diferentes, sin embargo, si algo nos ha enseñado el mundo de la programación es que existen problemas que se repiten con el paso del tiempo, problemas que sin duda otros programadores se han topado y muy probablemente han resuelto, hey, y si no es así, tú puedes el primero en resolverlos.

Antes de comenzar a escribir tu sentencia SQL, preguntaté, ¿Es probable que lo que este intentando hacer ya se encuentre implementado en otro lugar?, si crees que la respuesta es si, entonces, tomate un par de minutos, y busca alguna implementación.

Si encuentras la solución pero su implementación esta pensado para otro gestor, quizás SQL server y tú usa MySQL, no te desanimes, que mejor forma de aprender que profundizar en la respuesta y dar tu propia implementación.

Si por otro lado la implementación es para tu gestor, cool ?.

No estoy diciendo que es una buena practica el hecho de copiar y pegar código sin antes comprender el por que de las cosas, para nada, lo que trato de decir es que si alguien ya publico una respuesta (En algún blog, vídeo, etc ...) tiene muchas más posibilidades que la respuesta ya haya sido validada por la comunidad.

Una caso así ocurrió en codigofacilito. Teníamos la iniciativa de mostrar en la parte superior de artículos, el artículo más popular en cuanto ha visitas y fecha de publicación. La pregunta fue obvia, ¿Esto ya esta implementado en algún otro lado?.La respuesta es si.

Encontramos un artículo donde se daba una implementación.

No re inventemos la rueda. Si podemos utilizar algo que ya ha sido validado por cientos, quizás miles de programadores, en mi opinión lo hagamos.

No te compliques.

No por que tu consulta cuente con cientos de líneas es mejor.

Siempre intentar hacer uso de todas las cláusulas y sub cláusulas que el motor de base de datos te ofrece.

Bonito es mejor que feo

SELECT nombre, apellido FROM usuarios WHERE nombre = 'Luis' or nombre = 'Rafael' or nombre = 'Uriel' or nombre = 'Marines'

Mejor

SELECT nombre, apellido FROM usuarios WHERE nombre IN ['Luis', 'Rafael', 'Uriel', 'Marines']

Conclusión

Es cierto que no todos nacemos sabiendo, la practica hace al maestro, quizás no conozcas todas las cláusulas o no sepas cuando utilizarlas, pero sin duda algo que siempre podemos hacer es estar en mejora continua. Si tu sentencia funciona, genial, felicidades, es un mérito que nadie te quita, pero, hey, ¿No habrá una forma en la cual el tiempo de respuesta disminuya en un diez por ciento? ¿veinte por ciento? ¿Cincuenta por ciento?. Siempre podemos buscar nuevas y mejores formas de realizar nuestros programas, es cuestión de investigar y ponerse retos. En esta ocasión fueron pequeños tips, sin embargo no dudes que existen otras formas en las cuales puedes mejorar, desde el modelado, hasta realizar trazas de ejecución.

Recomendaciones

Ediciones de Java

Lo lees en 3 Min.

Plataformas en Java Java, a diferencia de otros lenguajes de programación, posee diferentes ti...

 

Cómo funciona la maquina virtual de Java

Lo lees en 2 Min.

Una de las principales características de Java es que una vez nosotros codificamos un programa ...

 

Deploy de una aplicación de Angular en Firebase

Lo lees en 6 Min.

Firebase es una suite de servicios que automatiza algunos de los elementos del desarrollo de un...

 

Qué es y cómo funciona Bitcoin

Lo lees en 10 Min.

BlockChain, es sin duda una de las palabras de moda en la actualidad, mucho se habla de ello, per...