Esta es la segunda de una serie de tres partes cuyo objetivo es introducir qué son las bases de datos y dar algunas opiniones sobre las tecnologías de bases de datos disponibles, por qué deberías usarlas y cuándo deberías usarlas de una forma no técnica. Ya hemos respondido a la pregunta de "¿Por qué usar una base de datos?" y ahora respondemos a la de "¿Qué base de datos debería usar?".
La siguiente información, aunque proviene de desarrolladores de LabVIEW, es generalmente válida para el desarrollo en cualquier lenguaje. Ahora que tenemos una idea clara de algunas de las ventajas de utilizar una base de datos en nuestras aplicaciones, ahora debemos responder a las preguntas de alto nivel de: (1) ¿Qué tipo de base de datos debo utilizar? y (2) ¿Qué tipo de infraestructura necesito para soportar la base de datos elegida?
Una buena parte de las respuestas a la mayoría de las preguntas a la hora de elegir una tecnología SQL pueden responderse con las siguientes ideas:
- La sintaxis común de los comandos SQL es compatible con todas las versiones de SQL y, por lo general, los comandos y elementos complejos que no son "configurables" una vez que existe la base de datos son específicos de la tecnología SQL; lo que significa que , SI decides cambiar de tecnología SQL a mitad del desarrollo, no es un problema.
- Si tu base de datos sólo necesita existir localmente y no va a crecer hasta un tamaño increíble, utiliza SQLite.
- Si necesitas acceder a tu base de datos de forma remota y va a crecer mucho, no utilices SQLite.
- La mayoría de las tecnologías SQL disponen de un controlador ODBC (Open Database Connectivity) para facilitar la integración en los sistemas operativos basados en Windows.
Las tecnologías SQL más comunes son:
- SQLite (1)
- MySQL (2)/MariaDB(3)
- Microsoft SQL(4)
- PostgreSQL (Postgres) (5)
A todos los efectos, son prácticamente iguales, con la salvedad de que SQLite se considera una base de datos móvil y, por lo tanto, no proporciona ningún tipo de seguridad a nivel de aplicación y existe como un archivo en lugar de como un servicio.
La siguiente tabla resume algunas de las diferencias entre las tecnologías SQL más comunes.
| SQLite | MySQL/MariaDB | Microsoft SQL | PostgreSQL(Postgres) | |
| Código abierto | Sí | Sí | Sí | Sí |
| Linux | Sí | Sí | Algo* | Sí |
| Servidor | No | Sí | Sí | Sí |
| Sólo local | Sí | Sí | No | No |
| Seguridad de archivos | Sí | No | No | No |
| Seguridad de aplicaciones | No | Sí | Sí | Sí |
* No es tradicionalmente de código abierto, pero Microsoft va a publicarlo en Linux, por lo que es en cierto modo de código abierto.
Como puedes ver, las principales diferencias tienen que ver con la naturaleza "móvil" de SQLite. Aunque es una gran ayuda para las pequeñas aplicaciones que necesitan datos persistentes localmente, no es muy adecuado para las aplicaciones distribuidas en las que varias conexiones interactúan simultáneamente con los datos almacenados en una base de datos. Las tecnologías SQL que soportan servidores, como MySQL y Microsoft SQL, pueden integrarse en una Infraestructura IT existente (donde las bases de datos pueden ya existir y ser mantenidas) para aliviar la barrera LabVIEW/datos y permitir a otras aplicaciones acceder a esos datos.
He mencionado ODBC antes, que es una interfaz de programación de aplicaciones (API) para acceder a diferentes tecnologías de bases de datos. El mejor ejemplo de LabVIEW de cómo ODBC puede facilitar los proyectos es que el LabVIEW Database Connectivity Toolkit (LVDCT) puede interactuar con cualquier base de datos que tenga un driver ODBC, haciendo que su código de base de datos sea relativamente portable con la necesidad añadida de que su aplicación tenga una dependencia que incluya un driver ODBC y un sistema operativo Windows.
Lo anterior debería darte una breve introducción sobre cómo elegir una tecnología SQL y los pros, contras y casos de uso de cada una.
En la próxima entrega de esta serie de blogs, abordaremos la idea de la escala: ¿cuántos datos son muchos datos y necesito un servidor?
- Por Parte de la documentación de SQLite, que ha sido liberada por el autor D. Richard Hipp al dominio público. Conversión a SVG por Mike Toews. - SVG creado a partir de sqlite370.eps, distribuido con la documentación de la versión 3.7.2, dominio público, https://commons.wikimedia.org/w/index.php?curid=11675072.
- https://en.wikipedia.org/wiki/File:MySQL.svg
- Por Mackphillips (Obra propia) [CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0)], a través de Wikimedia Commons
- https://blogs.msdn.microsoft.com/cdndevs/2015/03/11/python-and-data-sql-server-as-a-data-source-for-python-applications/
- Por Daniel Lundin - https://wiki.postgresql.org/images/a/a4/PostgreSQL_logo.3colors.svg, Licencia PostgreSQL, https://commons.wikimedia.org/w/index.php?curid=1395316
