¿Alguien podría diferenciar qué es mejor usar SQLite o SQL Server? Estaba usando un archivo XML como almacenamiento de datos. AGREGAR, borrar, actualizar ... Alguien sugirió usar SQLite para una operación rápida, pero no estoy familiarizado con SQLite. Sé SQL Server.SQLite vs SQL Server
SQLite es una gran base de datos integrada que implementa junto con su aplicación. Si está escribiendo una aplicación distribuida que los clientes instalarán, entonces SQLite tiene la gran ventaja de no tener ningún instalador o mantenimiento por separado: es solo una DLL que se implementa junto con el resto de su aplicación.
SQLite también se ejecuta en proceso y reduce una gran parte de la sobrecarga que trae una base de datos: todos los datos se guardan en caché y se consultan durante el proceso.
SQLite se integra mejor que su servidor SQL con su aplicación .NET. Puede escribir funciones personalizadas en cualquier lenguaje .NET que se ejecute dentro del motor de SQLite, pero que aún estén dentro del espacio y el proceso de llamada de la aplicación y así poder llamar a su aplicación para integrar datos adicionales o realizar acciones mientras se ejecuta una consulta. Esta habilidad inusual hace que ciertas acciones sean significativamente más fáciles.
SQLite es generalmente mucho más rápido que SQL Server.
Sin embargo, SQLite solo admite un único escritor a la vez (es decir, la ejecución de una transacción individual). SQLite bloquea toda la base de datos cuando necesita un bloqueo (ya sea de lectura o escritura) y solo un escritor puede mantener un bloqueo de escritura a la vez. Debido a su velocidad, esto en realidad no es un problema para aplicaciones de tamaño bajo a moderado, pero si tiene un mayor volumen de escrituras (cientos por segundo), entonces podría convertirse en un cuello de botella. Hay una serie de soluciones posibles, como separar los datos de la base de datos en diferentes bases de datos y almacenar en caché las escrituras en una cola y escribirlas de forma asincrónica. Sin embargo, si es probable que su aplicación cumpla con estos requisitos de uso y aún no se haya escrito para SQLite, entonces es mejor usar otra cosa, como SQL Server, que tenga un bloqueo más detallado.
ACTUALIZACIÓN: SQLite 3.7.0 agregó un nuevo modo de diario llamado Bloqueo anticipado que admite la lectura concurrente mientras se escribe. En nuestra prueba de contención multicriterio interna, el tiempo pasó de 110 segundos a 8 segundos para la misma secuencia exacta de lecturas/escrituras polémicas.
Solo discutiría la opinión de que "SQLite se integra con su aplicación .NET * mejor * que el servidor SQL". [énfasis añadido] Ambos pueden integrarse con una aplicación .NET aunque de diferentes maneras. Puede definir clases CLR en SQL Server y enviar instancias de estas clases entre el cliente y el servidor. En SQlite, puede crear UDF personalizadas en un lenguaje .NET que se puede importar a SQLite. Además, una frase como "aplicaciones de tamaño bajo a moderado" no tiene sentido. ¿Qué quieres decir con "tamaño"? – Tim
@Tim, llamé específicamente de bajo a moderado ya que requería hasta * cientos de escrituras por segundo *. Por encima de esa cantidad, la contención se vuelve demasiado problemática. –
Hola Samuel, ¿sqlite admite todas las funciones de sql? O no debido al límite de arquitectura ligera que utiliza la función. –
Ambos están en diferentes ligas en total. Uno está construido para la gestión de datos a nivel empresarial y otro es para dispositivos móviles (entorno integrado o sin servidor). Aunque las implementaciones de SQLite pueden contener datos en muchos cientos de GB, pero eso no es lo que está diseñado.
Actualizado: para reflejar la pregunta actualizada: Lea this blog post en SQLite. Espero que eso te ayude y te permita acceder desde redireccionarte a recursos para acceder mediante programación a SQLite desde .net.
También es una comparación falsa. ¿Está comparando las soluciones db-en-un-archivo (por ejemplo, SQLite, MS Access) frente a los RDBMS "reales" (por ejemplo, Oracle, SQLServer, PostgreSQL, MySQL)? ¿Estás simplemente comparando cosas con "SQL" en el nombre? ;-) Hay tantos criterios que está ignorando aquí (código abierto versus comercial: SQLServer es comercial, por ejemplo, mientras SQLite es de código abierto); columnas tipadas frente a columnas sin tipo (las columnas SQLite están esencialmente sin tipo); escalable frente a pequeña escala; etc. –
@Breakhead, si esto es para su uso personal o si las escrituras en la base de datos no son hechas simultáneamente por múltiples usuarios, y si la seguridad de los datos no es una preocupación, SQLite probablemente lo hará bien, incluso con enormes cantidades de datos . Puede pensar en SQLite como un sustituto del motor de datos MS-Access "JET"; no es un motor de base de datos de cliente-servidor fidedigno como SQLServer u Oracle. – Tim
Puede considerar la persistencia de objetos con estado. He estado usando esta técnica y funciona bastante bien.Cuando traté de reemplazar los objetos stateful persistentes con SQLite, encontré que SQLite era mucho más lento, tanto que tuve que descartarlo por completo y volver a los objetos persistentes. – John