¿No se subestima un poco SQLite? [cerrado]

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.

Hay muchas instancias donde SQLite es suficiente. El usuario, el departamento o la empresa rara vez lo superan (no escuchamos tanto porque nadie llama a un programador si la aplicación funciona bien). Podría argumentar lo mismo para un archivo de MS Access (Windows) o SQL Server Compact Edition (requiere instalación). Todos son lo suficientemente buenos para una aplicación local porque no tiene que preocuparse tanto por la seguridad del archivo.

En un escenario multiusuario en una red local, el archivo irá a una carpeta compartida a la que todos los usuarios necesitarán acceso: seguridad de llamadas. El mantenimiento simple o cualquier cambio en la estructura de la tabla, como copias de seguridad o agregar una columna, impedirán el acceso de otros usuarios. Anoche la copia de seguridad no funcionó porque alguien olvidó salir de la aplicación. ¿Qué sucede cuando quieres hacer una copia de seguridad a la mitad del día? Todos racionalizan que no necesitan copias de seguridad durante el día debido a las limitaciones técnicas de su base de datos. En algún momento, la instalación de SQL Server Express / otro equivalente en su servidor requerirá una configuración inicial y una configuración de seguridad, está más involucrado por adelantado, pero se requerirá poco mantenimiento.

Siempre existe la preocupación por la escalabilidad / sobre ingeniería. Incluso si el número de usuarios o la cantidad de datos aún es manejable, alguien siempre tiene la idea de utilizar los datos en vivo en alguna intranet u otra interfaz de sitio web / navegador. Las bases de datos de archivos presentan problemas. Solo se necesita una persona que quiera acceder al archivo de datos a través de una VPN (la aplicación está instalada en su computadora portátil) para darle un problema de 'escala'. Puede crear la aplicación para permitir que los usuarios desconectados puedan sincronizarse cuando regresen. Simplemente no parece que valga la pena para el usuario ocasional fuera de la oficina.

Creo que es genial usarlo cuando necesitas una base de datos "interna". Es decir, una base de datos con la que interactuará su aplicación / código, pero que no estará directamente relacionada con la razón principal por la que existe su aplicación. En lugar de utilizar grandes asignaciones en memoria o administradores de caché, también puede utilizar una base de datos de este tipo, por ejemplo. Tengo un ejemplo muy concreto de esto, ya que lo usé recientemente en casos de prueba JUnit / DBunit donde necesitaba conectarme a una base de datos, realizar algún trabajo, leer datos y borrar todo al final. Como solo necesita crear un archivo vacío para crear la base de datos , fue bastante fácil de hacer.

Otro uso que veo: cuando solo tienes un usuario. Sí, eso es posible, piense en "Firefox" u "Opera", por ejemplo :-)

Además, en el sitio web de SQLite son muy honestos al respecto y dan razones para NO USARLO (consulte el párrafo "Situaciones en las que otro RDBMS puede funcionar mejor")

ps: relacionado con los comentarios sobre Sql Server Express, sí, debe "instalarse". Y tuve algunos problemas para actualizarlo personalmente (tuve que eliminar manualmente algunas claves de registro relacionadas con la versión anterior para poder instalar el 2008 R2). Sin embargo, si desea comparar SQLite con una base de datos desarrollada por Microsoft, consulte Sql Server Compact Edition , que no necesita instalar (consulte "implementación basada en archivos privados").

Por ejemplo: considere una aplicación ERP con, digamos, 15 usuarios. ¿Por qué no se puede usar SQLite para eso?

Muy pocas aplicaciones tienen pocos usuarios para siempre. Y para cualquier cosa que vea más usuarios y una manipulación de datos más compleja, el uso de SQLite está completamente fuera de discusión por razones de rendimiento debido al simple modelo de bloqueo "una transacción de escritura a la vez".

Digamos que tiene 100 usuarios, cada uno trabajando durante 60 segundos completando un formulario y luego enviándolo. Por lo tanto, debe procesar aproximadamente 1.6 transacciones por segundo. El modelo de datos es complejo y guardar un formulario implica leer y escribir en muchas tablas grandes, tal vez incluso comunicarse con un sistema diferente, por lo que cada "envío de formulario" da como resultado una transacción que demora 2 segundos. Pero SQLite no puede procesar transacciones simultáneamente, por lo que esto significa que solo puede procesar 0.5 transacciones por segundo. Ups

"Puede ser un problema instalarlo" no es una buena razón para optar por una infraestructura crítica. Además, hay otros motores de base de datos para elegir, al menos dos de los cuales (MySQL y Postgres) son gratuitos y no tienen las limitaciones de concurrencia de SQLite. Incluso pueden ser más fáciles de instalar que MS-SQL.

Creo que SQLLite es excelente para el desarrollo de aplicaciones, su mayor fortaleza es que no necesita ser instalado en el cliente.

Sin embargo, tampoco subestime SQL Server Express, es una excelente base de datos gratuita con la mayoría de las características del servidor SQL ordinario con solo una limitación en el tamaño de la base de datos (que es difícil de exceder) junto con la capacidad de usar las excelentes herramientas normales servidor SQL.

Su mayor inconveniente es que necesitas instalarlo, aunque estoy un poco inseguro de esa parte, podría ser una forma de evitarlo ahora

No considero SQLite como una base de datos seria si se trata de unos pocos GB de datos cada hora. Se vuelve dolorosamente lento y reduce el rendimiento de toda la aplicación. Lo siento, pero no estoy de acuerdo con tu fascinación por SQLite :-)

El problema con las bases de datos es que tienden a acumular más y más datos. Elegir una base de datos liviana presenta el riesgo de que su herramienta no se ajuste correctamente.