Desde hace tiempo que supe de SQLite, pero cada vez es más y más su mención y uso, que finalmente me vi obligado a hacer su página de apuntes para poder facilitarme el recordar algunas cosas (además de tener una referencia ligera, pues ya la he usado en algunos cursos que he impartido). Estuve tentado a incluir esta entrada en una quizás más adecuada, pero sólo sería para uno de los puntos que quiero mencionar y la totalidad de este post no quedaría bien ubicado ahí y estoy previendo que el tema de esta estrada se extienda a un par de posts más.

Al ser un SMBD pequeño, que es adecuado para ser incrustado (embedded) en algún otro producto o sistema (especialmente uno de entorno específico o recursos limitados), uno tiende a despreciarlo o considerarlo como «poca cosa» y prefiere referirse a los «grandes y verdaderos SMBD«, que no dejan de ser prejuicios al final. Uno llega a ver a SQLite como un mero manejador de archivos también, pero eso es equivocado. Si bien no sigue la idea arquitectónica general de un SMBD, eso no cambia lo que hace.

Claro que también está el otro extremo. Ya me ha pasado que me he topado con el desarrollo de un sistema de información (aunque sea a nivel de prototipo) en el que, en lugar de usar un SMBD que pueda ser considerado como más adecuado para ser escalable (que es uno de los temas y preocupaciones de actualidad), se optó por usar SQLite (y quizás sin diseño ni consideraciones inicales al respecto sobre lo que sería el componente de BD). Todo el desarrollo se hace alrededor de SQLite y al final se obtiene algo. Ese algo funciona, y puede que funcione muy bien, pero queda atado al contexto de un SMBD pensado para un contexto o entorno restringido y limitado. Al final hay que reconsiderar y rehacer cosas, SQLite no puede ser cambiado por otro SMBD como un bloque de Lego.