¿No se subestima un poco SQLite? [cerrado]

15

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.

database database-development
fuente
99
Lo sentimos, pero agregando "¿Tengo razón?" no convierte una diatriba en una pregunta.
pdr
1
@pdr: ¿Por qué consideras esto una diatriba? No estoy juzgando negativamente MS-SQL u otras bases de datos; en su mayoría son productos excelentes. Solo estoy compartiendo mis pensamientos y estoy interesado en escuchar las opiniones de otros programadores. Nada más y nada menos.
3
No hay duda allí, solo una búsqueda de validación. De las preguntas frecuentes: "Solo debe hacer preguntas prácticas y con respuesta en función de los problemas reales que enfrenta. Las preguntas charlatanas y abiertas disminuyen la utilidad de nuestro sitio y hacen que otras preguntas salgan de la página principal". programmers.stackexchange.com/faq
pdr
1
@pdr: Entiendo eso, pero honestamente quise hacer una pregunta aquí. Tal vez no estaba claro, así que reformulé la pregunta.
44
Elección de base de datos, optimización de código, cliente, servidor o aplicación basada en web, todas estas son áreas de consideración y los pros y los contras deben discutirse en una plataforma como esta. Para mí, una queja es más cuando alguien se rehúsa categóricamente a encontrar alguna calidad redentora en una tecnología en particular.
JeffO

Respuestas:

8

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.

JeffO
fuente
Podría hacer el mismo argumento para SQL Server Compact Edition, pero no para una base de datos MS Access. Las bases de datos de Access se tratan como si fueran una base de datos real, pero funcionan más como archivos compartidos. Son una solución frágil; SQL Server Compact es en realidad una alternativa mejor, más rápida y más confiable que todavía funciona con las interfaces de Access. Sospecho que SQLite es sustancialmente más duradero que una base de datos de Access, aunque técnicamente es una solución de archivo compartido.
Robert Harvey
@RobertHarvey: tenemos demandas comerciales en las que MS Access ha sido una solución suficientemente buena (es decir, mejor que Excel) durante 10 años. Cuando se llega a un acuerdo importante, tenemos que tener algo en funcionamiento. Los usuarios avanzados con habilidades de acceso son mucho más fáciles de encontrar y aprovechar. La funcionalidad tiene que estar allí en una fecha determinada, pero tenemos la suerte de que la escalabilidad, el rendimiento, el crecimiento de los datos y la seguridad nunca hayan sido un factor. Actualización de Access, ahora esa es una historia diferente.
JeffO
No me malinterpretes; Creo que Access es genial. Pero SQL Server Compact sería mi requisito mínimo de back-end para cualquier nueva aplicación de Access donde los usuarios compartan datos.
Robert Harvey
@RobertHarvey: tendré que investigar eso. Gracias
JeffO
12

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").

Jalayn
fuente
Miré a CE, pero de alguna manera parece que SQLite es mejor / más rápido / más fácil. No estoy seguro, no usé / probé CE lo suficiente como para estar seguro.
5

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.

Michael Borgwardt
fuente
Entiendo y acepto. Pero en mi profesión realmente no tengo clientes que usen nuestros productos (estándar y personalizados, en su mayoría relacionados con ERP) con más de 10 personas. En promedio es incluso 5-6 usuarios. Reformularé mi pregunta.
44
@Marcus V: La pregunta es: si un cliente ha crecido mucho y encuentra que la aplicación que creó se vuelve extremadamente lenta de usar, y usted les dice que la razón es que el DBMS no puede manejar tantos usuarios, y preguntan " ¿por qué no usaste un mejor DBMS "? ¿Cómo crees que se recibiría la respuesta" esos son difíciles de instalar "? Puedo decirle cuál sería mi reacción: pensaría "este es un aficionado. Necesito encontrar a alguien más para escribir mi software".
Michael Borgwardt
Tienes razón. No creo que lo hayas dicho de esa manera, pero puedo asegurarte que no soy un aficionado. Definitivamente usaré sistemas DBMS "reales" si la situación lo solicitara. Nuestros productos tienen licencia para varios usuarios. Solo desarrollaría usando SQLite si sé que el número de usuarios es relativamente pequeño (<10-15). Si el cliente excede un límite, que en nuestra base de clientes no sucederá pronto, siempre podemos convertirlos de manera relativamente rápida / simple en otra base de datos. Eso no es ciencia espacial;). En función de sus comentarios, reformulé la pregunta para que quede más clara.
El usuario que llora por haber superado la aplicación probablemente fue informado sobre las limitaciones del usuario, pero eligió seguir la ruta más barata. Todo está bien en la configuración inicial, pero ¿qué tan felices estarán cuando tenga que cobrarles otra tarifa para instalar en el nuevo servidor, cuando podrían haber copiado un archivo?
JeffO
1
@Jeff O: Creo que entendiste mal mis intenciones. Estoy no elegir SQLite porque es gratis, barato y / o fácil de instalar. Lo elegiría solo porque es pequeño, rápido y amigable con los recursos. Por lo tanto, es principalmente por razones prácticas / técnicas. Muchos de nuestros clientes no gastan mucho en hardware, por lo que a menudo encuentro un único servidor con todo (Exchange, SQL, 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, MSSQL sí.
4

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

Homde
fuente
2
Tienes razón. MS-SQL Express es un producto de buena calidad. Es solo que me parece un poco hinchado y que uso demasiados recursos. En la actualidad, las PC / servidores no son un problema. Soy una persona de la vieja escuela que todavía piensa que un hardware más potente no significa que deba descuidar / desperdiciar recursos si puedo evitarlo. Menos es mejor ...;).
2
la base de datos con motores de base de datos puede optimizar el acceso al almacenar en caché la memoria en lugar de leer / escribir desde discos. Pero no estoy seguro sobre el rendimiento de la base de datos en proceso como SQL Lite
sarat
1
@sarat: Afaik SQLite utiliza memorias caché de forma intensiva.
2

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 :-)

Friki
fuente
1
Respeto tu opinión. Solo soy un hombre práctico. Cuando elijo una herramienta, la elijo porque creo que es la decisión más realista / práctica. No estoy fascinado con SQLite, pero admiro la forma en que lograron poner tanto en un paquete tan pequeño, eficiente y rápido. Como mencioné en mi pregunta: si MS-SQL es una mejor herramienta para un trabajo en particular, entonces simplemente elegiría eso. Pero, como expliqué, en muchas ocasiones realmente creo que SQLite se adapta bien.
Esa cantidad de uso de datos es un gran si.
JeffO
@ Jeff O: Correcto. Solo elegiría SQLite si el número de usuarios es relativamente bajo (<10-15) y también la cantidad total de datos no es alta. En nuestra experiencia, el tamaño total de la base de datos suele ser de 300-400 MB y casi nunca> 1 GB.
1

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.

cuant_dev
fuente