Estoy haciendo programación de bases de datos utilizando Java con SQLite.
Descubrí que solo una conexión a la vez a la base de datos tiene capacidades de escritura, mientras que muchas conexiones a la vez tienen capacidad de lectura.
¿Por qué la arquitectura de SQLite se diseñó de esta manera? Mientras las dos cosas que se escriben no se escriban en el mismo lugar en la base de datos, ¿por qué no pueden aparecer dos escrituras a la vez?
Debido a que "múltiples escrituras simultáneas" es mucho más difícil de lograr en el motor de base de datos central que un escritor único, un lector múltiple. Está más allá de los parámetros de diseño de SQLite, e incluirlo podría subvertir el tamaño y la simplicidad deliciosamente pequeños de SQLite.
La compatibilidad con altos grados de concurrencia de escritura es un sello distintivo de los grandes motores de bases de datos como DB2, Oracle, SQL Server, MySQL, PostgreSQL, NonStop SQL y Sybase. Pero es técnicamente difícil de lograr, ya que requiere un extenso control de concurrencia y estrategias de optimización como el bloqueo de bases de datos, tablas y filas o, en implementaciones más modernas, Control de concurrencia multi-versión . La investigación sobre este problema / requisito es voluminosa y se remonta a décadas .
SQLite tiene una filosofía de diseño muy diferente de la mayoría de los DBMS centrados en el servidor que admiten múltiples escritores. Está diseñado para llevar el poder de SQL y el modelo relacional a aplicaciones individuales y, de hecho, se puede integrar dentro de cada aplicación. Ese objetivo requiere compensaciones significativas. No agregar la infraestructura significativa y la sobrecarga necesaria para manejar múltiples escritores simultáneos es uno de esos.
La filosofía se puede resumir en una declaración sobre :
SQLite no compite con las bases de datos cliente / servidor. SQLite compite con fopen ().
Porque no hay un servidor que pueda decir si las cosas se escribirán en el mismo lugar o no. Solo hay dos procesos que intentan escribir en un archivo.
Como se señaló en un comentario, las escrituras concurrentes también podrían ser compatibles con un hilo interno. No estoy seguro de qué tan bien funcionaría esto (tampoco lo pensé mucho). De todos modos, aquí está la razón por la que SQLite no usa hilos: el Dr. Hipp piensa que los hilos son malos.
El hecho de que DR Hipp piense que los hilos son malos está documentado en las Preguntas frecuentes sobre SQLite .
Lea otras preguntas en las etiquetas database concurrency sqlite