|
No, no voy a hacer esa prueba que dices Casimiro, porque ya debes de saber que SQLite bloquea toda la base de datos por milisegundos requeridos para grabar.
La prueba que describo se debe de entender asi. Pero lo bello del SQLite3 es que es TAN RAPIDA que el tipico usuario en una aplicacion mediana, con datos tipicos de facturas, inventarios, altas, etc., no tiene problema en brindar multiusuario y escritos concurrentes.
Cada aplicacion es "su propia maquinita" y se comunican unas a otras atravez de archivos temporales.
Ahora, esto que les mencione brevemente, es tambien MUY IMPORTANTE para quien desea (ahi si) que haya mucha mas concurrencia permitida, es que SQLite puede conectarse con hasta 10 bases de datos, cada base de datos puede tenter un numero enorme de tablas, y cada tabla un numero enorme tambien de campos. Todos esos "enormes" son miles.
Cuando conecta una aplicacion a varias bases de datos, TODAS las bases y sus tablas son accesibles a comandos SQL, como si fuera una sola base de datos.
Entonces pues, ahi Usuario1 grabando datos en Base de datos 1, y Usuario 2 grabando en base de datos 2, no ven ni uno de los dos NINGUN lock.
Quiere decir que para un negocio tipico, en el que una sola base de datos no fuera adecuada, se pueden repartir el archivo de escritos mas frecuentes en su propia basededatos, y los menos frecuentes en otra. Si hay mucho trafico, para otro tipo de archivo, se usa OTRA mas, base de datos.
Todas esas bases de datos son relacionales, conforman a integridad referencial. Inclusive, tiene SQlite el sistema de "triggers" que son un equivalente a "stored procedures" que tambien se pueden considerar en cuanto a rendimiento.
Lo que dije antes, no he logrado que se corrompa ni una sola de las bases de datos, a pesar que les he dado bastante duro.
Lo que todos ustedes saben es que hay muchas tecnicas posibles para hacer las cosas mejor, o superar limitaciones, y con SQLite eso no es la excepcion.
Pongo esto por lo que a alguien le pueda interesar o servir. Pero no hay nada mejor que cada quien buscar lo mas aproximado a lo cierto.
Hasta luego.
P.S. No vayan a salir conque repartir archivos es un truco o es algo inferior, pues les recuerdo que de hecho, ASI trabajan muchas bases de datos: usan un archivo para cada tabla, y ESO en gran parte es lo que les da mas concurrencia. Y esto es lo mismo aun en las bases de datos mas poderosas. Postgres, por ejemplo, asi lo hace. Claro que tienen mecanismos mucho mas avanzados para repartir el trabajo y la data.
Última edición por ElMug fecha: 06-09-2012 a las 21:31:47.
|