Hace no mucho tiempo me vi embarcado en un proyecto que prometía ser algo grande. Muchas visitas y mucho contenido, no sólo textos e imágenes, sino también multimedia. Un portal con grandes cantidades de información didactica destinado a los estudiantes.
Según las especificaciones iniciales MySQL sería el motor para gestionar la base de datos, pero como otras tantas veces, el cliente disponía de su propio servidor, que además era gratuito y quería aprovechar por todos los medios, y como no podía ser de otra manera (ocurre más veces de las que debiera), nos encontramos con una serie de limitaciones que puso al equipo técnico en una situación difícil: la base de datos en dicho servidor era SQLite. Así que…o desarrollábamos con SQLite o nos buscábamos otro alojamiento para el proyecto.
Nos paramos a pensar fríamente y planteamos seriamente cuál de las dos opciones debíamos utilizar, ya que la elección final, para bien o para mal, definiría el futuro del proyecto.
En ese punto, llegó la investigación de los pros y los contras tanto de MySQL como de SQLite teniendo en cuenta las necesidades mínimas de usuarios y contenidos ya comentados.
Antes de nada, documentarse. Siempre hay que buscar información y contrastar tanto de los sitios oficiales como de los usuarios y administradores, en este caso, de MySQL y SQLite, para después saber qué es lo que más nos conviene y, por supuesto, poder dar buenas razones y explicaciones a los que manejan la pasta de por qué no se podía aprovechar su servidor y que haría falta gastarse el dinero en otro, puesto que la posibilidad de instalar otro sistema de base de datos tampoco se podía contemplar.
Finalmente, tras leer los comentarios de otros sitios y alguna que otra entrada en foros y blogs, destaco la siguiente información: Cuándo usar SQLite y cuándo no.
Del enlace anterior y demás sitios consultados tengo que resaltar los siguientes puntos:
SQLite:
- puede funcionar perfectamente para sitios de tráfico bajo-medio, lo cual se traduce en el 99,9% de los sitios web actuales.
- es mono-usuario, es decir, no permite concurrencia de conexiones, aunque he leído varias cosas diferentes sobre esto. Si un usuario está modificando datos, otro no podrá hacerlo hasta que el anterior no termine.
- no es una base de datos, sino un fichero con datos debidamente organizados (esto me recuerda al Access de Microsoft). Para hacer una copia o migrar la aplicación basta con mover el fichero de sitio y listo.
- no tiene tipos de datos…¿?…esto sí que no me gusta nada. Puedes meter una cadena de texto en un campo que estás utilizando como numérico. Esto me lleva a pensar en la cantidad de problemas que pueden ocurrir.
- no hay gestión de usuarios. La seguridad se basa en el sistema de permisos de ficheros establecido por Unix/Linux.
MySQL:
- funciona con sitios de gran envergadura. Hay que tener en cuenta que es utilizada en proyectos como Wikipedia, phpBB, WordPress, Drupal, Joomla…
- es un gestor de base de datos, y cada tabla está en un fichero diferente, así como vistas y otros objetos.
- permite múltiples consultas y modificaciones al mismo tiempo. Pongo “múltiples” por decir algo, pero se entiende que cientos de miles es un número aceptable
- tiene varios tipos de datos para según qué tipo de información necesitemos manejar.
- posibilidad de gestionar usuarios con diferentes niveles de acceso.
Resumiendo, que quedó bastante claro que lo que se necesitaba para que el proyecto llegara a buen puerto y sin miedo de estar pisando tierras movedizas era utilizar, sin lugar a dudas, MySQL 
Por suerte esto se pudo hacer y finalmente el proyecto se hizo con MySQL, pero por desgracia, como pasa con muchos proyectos, los que manejaban la pasta cerraron el grifo. Cuesta mucho asimilar algo así, especialmente cuando el desarrollo se había completado, nada más y nada menos, que al 98%.
Un proyecto prometedor que resultó ser un fiasco y que, además, dicho sea de paso, el desarrollo resultó ser una auténtica tortura.
