Antes de hacer la pregunta, permítanme describir primero mis pensamientos sobre SQLite.
Me gustan las herramientas que son pequeñas, rápidas y, lo que es más importante, que solo tienen la funcionalidad realmente necesaria. Es por eso que me gusta SQLite y me gusta MS-SQL un poco menos.
Por ejemplo: MS-SQL puede tener mucha más funcionalidad, escalabilidad, etc., etc., pero también puede ser complicado instalarlo si no tiene suerte. Por supuesto, no digo que una instalación difícil sea una razón para no elegir una base de datos en particular.
No me entiendas mal: MS-SQL es un producto de buena calidad. Tengo mucha experiencia con MS-SQL; Entiendo el producto muy bien como profesional. Simplemente lo prefiero menos en algunas circunstancias donde realmente no es necesario (= no muchos usuarios, <10-15).
¿Qué parte de la funcionalidad de una base de datos utiliza realmente? En mi experiencia, a menudo es solo el SQL normal (SELECCIONAR, INSERTAR y ACTUALIZAR).
Me gusta SQLite Es fascinante rápido. Es extremadamente fácil de "instalar". Creo que SQLite puede hacer más de lo que dice que puede hacer. ¿Por qué solo usarlo para aplicaciones de un solo proceso / usuario único? Después de todo: no muchas aplicaciones acceden constantemente a una base de datos.
Por ejemplo: considere una aplicación ERP con, digamos, 15 usuarios. ¿Por qué no se puede usar SQLite para eso? Seamos realistas: en mi experiencia profesional, la mayoría de las veces los usuarios de este tipo de aplicación accederán a la base de datos durante aproximadamente el 5-10% del tiempo total que están utilizando la aplicación. En el otro 90-95% solo están mirando la información en la pantalla, ingresando datos en una cuadrícula / formulario y cuando guardan su entrada, eso no es más de 1 segundo de tiempo de base de datos. Fe: 1,5 minutos de tiempo de entrada frente a 1 segundo de tiempo de ahorro.
Si el archivo de la base de datos SQLite está bloqueado durante el "ahorro de tiempo", otros usuarios que necesitan acceder a la base de datos simplemente esperan, pero no lo notan porque el tiempo de espera será muy pequeño (imperceptible). En el código solo tiene que lidiar con el posible tiempo "ocupado" de la base de datos, para evitar excepciones, pero eso no es difícil de hacer.
Un tipo, que debe pensar lo mismo que yo, incluso ha creado una solución cliente-servidor para SQLite: SQLitening . Esto me convenció más de que no me estaría engañando a mí mismo.
Por supuesto, hay aplicaciones intensivas en bases de datos donde SQLite no se ajusta. Pero ahora que lo pienso, muchas aplicaciones multiusuario, si no superan los 15 usuarios más o menos, deberían funcionar bien con SQLite.
Muchos de nuestros clientes no gastan mucho en hardware, por lo que a menudo encuentro un único servidor con todo lo que contiene (Exchange, SQL (s), clientes, etc.) y por eso están casi "sin aliento". Si pudiera entregar un producto que no tiene altos requisitos del sistema, entonces mi cliente estaría feliz. SQLite no agrega ningún peso (al menos no mucho), MS-SQL sí. Por lo tanto, no elegiría SQLite porque es gratuito, barato o fácil de instalar. Lo elegiría por razones prácticas / técnicas.
FYI: En mi profesión, vendemos productos (personalizados y estándar, en su mayoría relacionados con ERP) a clientes donde, en promedio, no más de 5-6 personas usarán el producto. Hay algunas excepciones, pero no más de 10-15 usuarios.
La pregunta es: ¿estoy en lo cierto al pensar que puedo usar SQLite para alguna aplicación multiusuario como el ejemplo que describo? ¿Hay alguna desventaja técnica que deba conocer? ¿Cuáles son sus experiencias (negativas o positivas) que me ayudarán a tomar la decisión correcta?
Actualización: Por favor, no vea esto como un juicio negativo de otras bases de datos. En su mayoría son productos excelentes. Simplemente compartiendo mis pensamientos aquí e interesado en sus opiniones sobre esto.