BD SQLite protegida por Usuario y Contraseña

[Casimiro Noteví]

Empezado por ElMug

Aca en Saturo todo es al revez: hasta el menos sabio sabe que DOS cosas no pueden estar al mismo tiempo en un solo lugar, que todas la bases de datos, hasta las mas robustas, usan sistemas de locks y esperas. En el planeta tierra, ni se diga, es como tumban los sitios ahi: con un tumulto de accesos. Y aunque los terricolas no lo sepan, o por discutir, se les olvida que "simultaneo" no quiere decir realmente "simultaneo", sino bastante rapido como para que PAREZCA "simultaneo". Las bases de datos tipo servidor usan muchos archivos, para "cachar" informacion mientras se libera el record o bloque donde tiene que hacerse la grabacion final. Muchas de sus base de datos se bloquean cuando no son de las mas robustas, y viven las esperas requeridas. SQLite es igual, o similar, bloquea por milisegundos, en transacciones tipicas, y usa archivos temporales escritos a disco o a memoria. Solo que es para uso LEVE en ese asunto. Y es por eso que se llama a si misma "lite", que quiere decir "ligera".

No, no es exactamente así.

[ElMug]

Explica, tu, como es, casimiro.

[ElMug]

Amigos del foro,

Les platico esto que les pueda ser de interes, en cuanto a el tema tratado en este hilo:

Hice una prueba usando una aplciacion que desarrolle , que puede mandar a una base de datos SQLite3 un conjunto de renglones para cargar le bastante data en una transaccion.

La data es real (la consegui del web) consiste de cargar 239 paises, o sea una tabla con 15 columnas y 239 renglones. Las columnas son codigo de pais,nombre de pais, continente, region, superficie, año de independencia, poblacion, vida promedio de habitantes, GNP, gnpANTERIOR, nombre local, tipo de gobierno, presidente o cabeza de estado, capital, codigo1, Codigo2.

En total son 3,585 datos a cargar a cada tabla.

Corri 2 instancias de la misma aplicacion, y a cada una la prepare para que mandara la misma data, CREANDO cada una tabla identica, pero con nombres Pais1 y la otra Pais2, a la misma base de datos, que ya cada instancia tenia abierta. Cada transaccion crea su tabla y la carga de datos.

Puse los botones de mando de cada aplicacion pegaditos (usando always on top) a manera de que pude hacer click una aplicacion y la otra al instante.

No recibi ningun mensaje de error, y casi ni lo creia, cuando vi que INSTANTANEAMENTE, se crearon en la MISMA base de datos DOS tablas, Pais1 y Pais2, identicas, cada una con 3585 datso reales cada tabla, que son 7,170 datos en total, contenidos en 239 renglones mult. por 2 = 478 renglones que cargo sin chistar.

Esto debio de haber ocurrido en milisegundos, pues hasta parecio que no habia habido respuesta a los dos clicks practicamente simultaneos, mas rapido no podria haber picado los botones uno tras otro, pues estaban pegaditos.

Si esto no es acceso concurrente, alguien tendria que tener base para negarlo.

Ahora, comparen lo que se tardarian operadores terricolas tecleando esta informacion y mandandola para grabarla, a la base de datos. Tal vez unos cuatro capturistas tardarian un par de dias en hacerlo y no veo como SQLite no tuviese la capacidad de manejarlos a todos simultaneamente.

Les aviso que soy pianista y puedo picar botones con mucha rapidez.

De todas maneras, les recuerdo que nunca dije, ni diria, que SQlite sea mejor que otra, pero que es multiconcurrente y mltiusuario, con sus limitaciones, claro, sostengo que SI lo es.

Bueno, hasta la vista.

[Casimiro Noteví]

Empezado por ElMug

Si esto no es acceso concurrente, alguien tendria que tener base para negarlo.

No, eso no es acceso concurrente.

[roman]

Empezado por ElMug

No recibi ningun mensaje de error, y casi ni lo creia, cuando vi que INSTANTANEAMENTE, se crearon en la MISMA base de datos DOS tablas, Pais1 y Pais2, identicas, cada una con 3585 datso reales cada tabla, que son 7,170 datos en total, contenidos en 239 renglones mult. por 2 = 478 renglones que cargo sin chistar.

Claramente, esto no es un acceso concurrente. Tendrías que haber insertado en la misma tabla para poder hablar de concurrencia y aún así, si no se repite la llave primaria, tampoco estarías hablando de concurrencia.

Yo entiendo tu defensa de SQLite, y también creo que el concepto de concurrencia es discutible, pero tampoco hay que exagerar y hacer ver a SQLite como uno de los grandes no Lite.

// Saludos

[Casimiro Noteví]

Amigo ElMug, si quieres hagamos una prueba, a ver si sqlite la pasa con éxito:

En una tabla donde tengas ya registros, o creas una nueva, no importa que sea simple, ejemplo:

Código SQL [-]
create table tbPrueba (
  id integer not null,
  nombre varchar(64),
  telefono varchar(9),
  importe float,
  primary key (id)
)

En esa tabla inserta 100, 500, 1000 registros, los que quieras.
El 'id' será la clave primaria, así que introduce 1,2,3,4,5,... 999,1000
El resto de campos, lo que te parezca, cualquier dato aleatorio.

Ahora crea un programita sencillo en plan rápido que haga esto:

Código Delphi [-]
var
  iX , iCodigo : integer;  
begin  
  query.close;
  query.sql.text := 'update tbPruebas set nombre= :nombre, importe= :importe where id= :id';

  for iX:=1 to 100000 do  // cien mil actualizaciones, para que dé tiempo probar.
  begin
    iCodigo := random(1000);  // esto devuelve un número aleatorio entre 1 y 1000 (o los registros que existan en la tabla)
    query.close;
    query.params[0].asstring := inttostr(iCodigo);
    query.params[1].asfloat := iCodigo;
    query.params[2].asinteger := iCodigo;
    query.execsql;
  end;
end;

Pones 1 botón y ejecutas. No debe fallar.
Ahora abres otra instancia del programita, vamos a simular 2 usuarios trabajando.
Ejecutas y pruebas. Si no falla, puede ser que no falle si no coinciden en actualizar el mismo registro.
Ahora abres otra instancia del programita, ahora serán 3 usuarios trabajando.
Y así hasta que te aburras. A ver qué ocurre.

Cuantos más registros tengas, menos posibilidades de que toquen el mismo registro al mismo tiempo.
Cuantos menos registros tengas, más posibilidades de que seleccionen el mismo.
Cuantos más usuarios al mismo tiempo, más posibilidades de que seleccionen el mismo.

Es sólo algo didáctico, por probar.

p.d. He puesto más o menos como debe ser el código, no tengo ningún delphi/lazarus para probar.

[roman]

Oye Casimiro, ¿y qué pasa en Firebird si hago esta misma prueba que propones? ¿Qué pasa si dos usuarios tocan el mismo registro al mismo tiempo?

// Saludos

[ElMug]

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.