Respuestas universales sobre SQL/Base de datos

[mamcx]

Viendo que cada vez hay más preguntas sobre SQL/bases de datos y el marcado desconocimiento sobre cómo usarlo, que es un producto del uso extendido de ORMs, NoSql y demás herramientas que intentan "abstraer" el acceso a datos, algunos tips para el que quiera mejorar en su uso de motores de base de datos relacionales.

Respuestas universales:

0. Tengo un problema y voy a preguntar en el club. ¿Por qué no me están respondiendo?

Luego de leer la guía de estilo general, no podremos responderte sin TUS DATOS ORIGINALES.

Recuerda que un programa es ENTRADA -> PROCESO -> SALIDA. Casi todas las preguntas aquí la gente muestra PROCESO -> SALIDA. Sin un ejemplo de las tablas/datos originales ANTES de ejecutar el proceso no hay cómo resolver nada de nada.

Es como si te pregunto:

¿Por qué suma me da 10 si debería dar 20?

Pero no dices qué datos se usaron para ese cálculo.

Para poder reproducir el problema, es ideal usar http://sqlfiddle.com/ con un ejemplo de los datos/indices y la consulta usada. De no poderse, usa https://gist.github.com/ o cualquier otro medio para mostrar los datos. Tambien vale ponerlos en un tag SQL del foro si es relativamente simple la tabla(s) de origen de los datos.

Recuerda: Un problema que no se puede reproducir no tiene como arreglarse.

1. ¿Cual motor de base de datos usar?

- Firebird/sqlite para bases de datos embebidas, que no requieran instalarse como un servidor/app aparte, o como BD de clientes desconectados/mobiles/remotos que sincronizan o tienen un sub-conjunto de los datos del motor primario.

- PostgreSql como motor primario. Es el más completo en funcionalidad y soporte al estándar SQL, estable, eficiente y con un gran ecosistema de herramientas y sub-engines para cubrir una gran cantidad de casos de uso, como el de reportería, minería de datos y demás.

Tiene una EXCELENTE documentación.

MS Sql Server está muy bien como motor comercial, y Firebird es una excelente opción. MySql es más complicado en su enorme variedad de versiones, engines, licenciamiento y facilidad de cometer errores invisibles que requieren entendimiento de las idiosincracias del motor. A menos que se tenga la experiencia, PostgresSQL es mucho más fiable y hay MUY POCOS escenarios donde mysql es realmente mejor.

ABSOLUTAMENTE dejar atrás motores obsoletos como paradox, dbase, access y similares. Si no tienes una buena razón para ello, son por mucho la peor opción al dia de hoy.

Motores NoSql SON PARA NICHOS ESPECIFICOS y a menos que REALMENTE entiendas cuándo y el porqué usarlos, es mejor apegarse a un RDBMS tradicional. En especial, cualquier motor que NO SEA ACID ES UN DOLOR DE CABEZA GARANTIZADO.

Si crees que eres muy listo porque ese motor NoSql es muy "escalable" (que normalmente es cierto) pero SQL te da dificultad, es garantizado que menos deberías usar NoSql.

Y por ultimo: USA LA ULTIMA VERSION ESTABLE DEL MOTOR. No tiene NADA de sentido usar una version antigua, con la única excepción de que ese motor no lo controlas y simplemente estás teniendo acceso a él. Si es uno de tus clientes, recomienda actualizarse tan pronto sea posible. Un RDBMS hay que tratarlo con MÁS RESPETO Y AMOR que el SO. Las versiones recientes tienen muchas mejoras, parches y demás que no quieras perderte.

2. ¿Por qué esto no me sale como quiero ...?

La mayoría de los problemas con SQL a la hora de obtener un resultado es ignorar que es un lenguaje completo y que sigue un paradigma DIFERENTE al orientado a objetos. Debido a su sencillez general es fácil lograr resultados inmediatos pero sin algo de estudio, muy difícil de resolver tareas mas complejas.

Así que:

- Lee sobre el modelo relacional:

http://infolab.stanford.edu/~ullman/focs/ch08.pdf

Ya que si sigues mirando la BD con ojos de programador OO estarás perdiendo la facilidad y eficiencia que te puede dar.

- Lee la documentación de SQL de tu motor. Si tu motor tiene documentación deficiente, lee la de PostgreSql, que debido a que sigue una cercana implementación del estándar de SQL es lo mas próximo a un dialecto universal:

https://www.postgresql.org/docs/10/static/index.html

Una vez hayas aprendido un dialecto y la idea general, adaptarse es trivial. De aquí, es aprender las idiosincracias del motor y cómo se administra (crear usuarios, hacer backup, etc).

- El sql "tradicional" está basado en el estándar ANSI SQL 92, o sea 1992. Eso es vieeeejo. Algo habrá avanzado la industria en estos años ¿no?

Los avances de última generación permiten resolver muchos problemas que antes eran muy complicados:

https://modern-sql.com/

En resumen:

No esperes que tu motor de bases de datos te funcione y la vez ignorar aprender sobre él y SQL.

3. ¿Cómo hago que mi consulta sea más rápida (o cómo hago que dé resultados esperados)?

Al igual que con el código general, el proceso de optimizar y el de hacer que funcione es casi el mismo:

- Hazlo simple
- Hazlo correcto
- Hazlo rapido

Lo MÁS MÁS importante es modelar tus tablas correctamente. Lo que significa, entender cómo normalizar Y denormalizar los datos, cómo nombrar las tablas, campos... cómo aplicar los índices adecuados, el uso de vistas, funciones & triggers para abstraer la BD (o sea: así como usas clases, funciones y eventos en código OO para abstraer el código, usas vistas, funciones & triggers para abstraer la BD).

Mientras que esto parece complejo, es MUCHISIMO más sencillo que hacer el código de un lenguaje OO. Las tablas son MUY visuales:

Muéstrame tus diagramas de flujo y esconde tus tablas y continuaré desconcertado, muéstrame tus tablas y usualmente no necesitaré tus diagramas de flujo; ellos serán obvios.

The Mythical Man-Month / Fred Brooks

Por lo tanto, si al ver las tablas, puedes decir "Sí, esto se entiende y es OBVIO cómo derivo todas las consultas que necesito" entonces muy seguramente tu BD está bien hecha. En cambio, si es lo contrario, GARANTIZADO AL 100% tu BD está mal hecha.

---

Para entender a tus consultas tienes que entender cómo funciona un RDBMS, que en resumen es más entender cómo funcionan los indices:

https://use-the-index-luke.com/

Y TODAS TUS PREGUNTAS A "¿POR QUÉ MI CONSULTA ES LENTA?" las resuelve el query planer.

Por lo tanto al organizar los datos correctamente y aplicar lo que query planer nos dice, tendremos una BD rápida y eficiente.

En resumen, estos son los pasos para una BD rápida:

1- Buen diseño de las tablas
2- Uso de índices correctamente
3- Investigar con el query planer cuando algo sea lento

y por demás:

4- Usa la última versión de tu BD. Actualízate, por el amor de Dios. En especial si ¡usas un motor gratuito!
4a - y lo mismo al SO. No te quejes si tu servidor sigue en Windows XP.
5- Pon tanta RAM como puedas en tu servidor
6- Pon la BD en un disco SSD, idealmente un SSD para servidores.

[Casimiro Notevi]

Lectura obligada

[Ñuño Martínez]

¿Cómo es posible que se me haya pasado este hilo? Me lo guardo pero ya.

Muchichísimas gracias.

[MAXIUM]

Maravillosa lectura. Gracias.