BD SQLite protegida por Usuario y Contraseña

[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.

[Casimiro Noteví]

Empezado por 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?

Firebird tiene una arquitectura "multigeneracional" y guarda distintas "versiones" del registro que está siendo consultado, editado, etc. y que según el nvel de aislamiento escogido para las transacciones trabajarán de distinta forma.
Si un usuario está editando un registro y otro usuario entra a editar el mismo registro, el último no ve los cambios que está haciendo el primero (mientras el primero no confirme los cambios), básicamente el último en escribir es lo que se mantiene
En la práctica, usando transacciones con los parámetros:
read_committed
rec_version
nowait
Es prácticamente imposible que sucedan "deadlocks", es más, yo jamás los he visto.

Mejor pego una explicación más técnica, no sé qué tal es la traducción:

Modelo de arquitectura multigeneracional (MGA)
Para implementar el mecanismo de transacciones, Firebird utiliza una arquitectura multi-
generacional (MGA). En este modelo, cada fila almacenada en la base de datos mantiene el ID de
transacción único de la transacción que lo escribió. Si otra transacción guarda cambios a la fila, el
servidor escribe en disco una nueva versión de la fila, con el nuevo ID de transacción, convirtiendo
una imagen de la versión vieja en una referencia (delta) de esta nueva versión. Así el servidor
mantiene dos versiones (generaciones) de la misma fila.
Las filas que se van creando en una transacción no serán visibles a las transacciones que se
inicien posteriormente mientras no se finalice mediante un commit. Si al hacer esta operación se
produce algún conflicto, el servidor devuelve una excepción al cliente y la confirmación falla.
Normalmente la solución es hacer un rollback por parte del cliente, por lo que se deshace toda la
transacción.
Un rollback nunca falla, por lo que cualquier cambio que se halla hecho durante una
transacción se podrá deshacer. En determinadas situaciones una operación de rollback no hace que se
borren físicamente las versiones de las filas del disco. Esto puede suceder cuando la transacción
realiza muchas actualizaciones de datos o cuando se rompe el servidor durante una transacción.
Las versiones de registros de las transacciones deshechas son eliminadas de la base de datos
cuando el sistema las encuentra en el curso de operaciones de procesado de datos. Por lo general, si
una fila es accedida por una sentencia, cualquier versión antigua del registro que puede ser elegible
para ser borrada, se marcará para que el proceso de recoleccion de basura (Garbage collection) la
elimine. Puede suceder que haya filas a las que no se accede normalmente, en este caso la recolección
de basura se realiza mediante operaciones como el backup.
En MGA, la existencia de una nueva versión de una fila pendiente de confirmar puede
bloquear la fila. En muchas situaciones, la existencia de una versión más nueva confirmada bloquea
una petición para actualizaro borrar la fila, en este caso se produce un conflicto de bloqueo. Esto nunca
sucede con las inserciones ya que no hay versiones delta ni bloqueos para la fila insertada. Sólo
fallaran éstas cuando se produzca una violación de alguna restricción.
Cuando se recibe una petición de actualización o borrado el servidor inspecciona el estado de
cualquier transacción que se propietaria de una versión más nueva de la fila. Si estas transacciones
están activas o se han confirmado, el servidor responde acorde al contexto (parámetros de nivel de
aislamiento y resolución de bloqueos) a la transacción solicitante.
Si la transacción con versión más nueva de la fila está activa, la transacción solicitante esperará
(valor por defecto) hasta que se complete la otra transacción (commit o rollback). y luego el servidor
permitirá que continue. Sin embargo, si se indica como parámetro NOWAIT, se elevará una excepción
por conflicto a la transacción solicitante.
Si la transacción con versión más nueva de la fila es confirmada y la transacción solicitante
está en nivel de aislamiento SNAPSHOT (concurrente), el servidor rechaza la petición e informa de un
conflicto de bloqueo. Si la transacción está en nivel READ COMMITED, con la configuración por
defecto RECORD_VERSION, el servidor permite la pertición y escribe una nueva versión del
registro.
Firebird no usa el metodo convencional de bloqueo en dos fases. En nuestro caso todo el
bloqueo es a nivel de fila y de tipo optimista, es decir, cada fila esta disponible para todas las
transacciones de lectura- escritura hasta que alguna escriba una versión más moderna de ella.
Tras una operación de confirmación correcta, con las versiones viejas puede ocurrir:
- Si la operación es una actualización, la nueva imagén se convierte en la última versión
confirmada y la imagen original del registro es marcada para recolección de basura.
- Si la operación fue un borrado, una marca reemplaza al registro obsoleto. Una operación de
sweep o backup limpia esta marca y libera el espacio fisico en disco ocupado por la fila
borrada.
En definitiva, bajo condiciones normales:
- Cualquier transacción puede leer cualquier fila que fue confirmada antes de que se iniciara.
- Cualquier transacción de lectura-escritura puede solicitarse para actualizar o borrar una fila.
- Se podrá confirmar una petición si no hay otra transacción de lectura-escritura que haya
confirmado un cambio a una versión más moderna de la fila. A las transacciones que
confirman lecturas normalmente se les permite indicar cambios que sobrescriben versiones
confirmadas por nuevas transacciones.
- Si se permite un cambio en una fila, la transacción bloquea la fila. Otros lectores pueden
leer la última versión confirmada de la fila, pero ninguna podrá indicar cambios mediante
operaciones de update o delete para la fila.
Se puede aplicar también bloqueo a nivel de tabla. Hay dos mecanismos para ello: indicando el
nivel de aislamiento para la transacción como SNAPSHOT TABLE STABILITY o al reservar la tabla
(select * from tabla for update with lock). Este bloqueo no se aconseja salvo en ocasiones puntuales.

Empezado por ElMug

No, no voy a hacer esa prueba que dices Casimiro

Así que sqlite permite miles de campos, eso está bien.
Amigo, no sé de dónde eres, pero por aquí decimos: "tú sigue en tus mundos de yupi"