BD SQLite protegida por Usuario y Contraseña

[Casimiro Noteví]

Empezado por roman

¿A qué te refieres con pagando?

A que pagando puedes añadir estas extensiones:

SQLite Encryption Extension (SEE)..... $2000
Compressed And Encrypted Read-Only Database (CEROD)..... $2000

Empezado por roma

Esto es discutible. Con todo y su antigüedad y sus limitaciones, Paradox, por ejemplo, bien puede decirse que es multiusuario. Puedes tener un sistema con una base Paradox y múltiples usuarios simultáneos. Claro que tienes que establecer bloqueos y fijarte si no hay uno al momento de escribir un dato, pero de que puede funcionar, puede.
Por otro lado, en un gestor `de verdad`, tampoco pueden, si nos ponemos muy estrictos, escribir al mismo tiempo varios usuarios. Bueno, de que pueden, pueden, pero, si vendiste el último par de calcetines, ¿te quedas así tan campante sin saber si otro vendedor ya lo hizo al mismo tiempo que tú? O, si modificaste los últimos lineamientos de ClubDelphi, ¿te quedas tranquilo sin pensar que a lo mejor yo también los modifiqué al mismo tiempo?
// Saludos

Lo digo por esto:

Varios procesos o hilos pueden acceder a la misma base de datos sin problemas. Varios accesos de lectura pueden ser servidos en paralelo. Un acceso de escritura sólo puede ser servido si no se está sirviendo ningún otro acceso concurrentemente. En caso contrario, el acceso de escritura falla devolviendo un código de error (o puede automáticamente reintentarse hasta que expira un tiempo de expiración configurable).

[roman]

Pues sí. Sé a lo que te referías. Pero lo que yo digo es que no necesariamente eso le quita el adjetivo multiusuario y que aún en los gestores que no te marcan un error cuando hay dos escrituras simultáneas, tienes que hacer verificaciones, o sea que no es que te den todo hecho para la simutaneidad.

// Saludos

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

En cuanto a encriptar a SQLite, hay como en casi todo hoy en dia, gratuito y a costo. Cual sirva o no sirva, no viene al caso sin tener como base la experiencia del haberlo verificado.

Pero, en Saturno como el el planeta Tierra, la mayoria de las bases de datos no usan encriptamiento y toda data que no este encriptada, se puede leer.

Alquien de este foro usa encriptacion en sus bases de datos?

[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

[ElMug]

Acceso multiconcurrente es que mas de un usuario pueda grabar en una base de datos, sin importar los mecanismos usados, y esto lo hace SQLite3 usando su Modulo Pager.

SQLite3 tambien usa dos copias de las transacciones y las usa para el roll-back y para controlar el uso simultaneo de escritos a una misma tabla.

[ElMug]

Aqui para los que dicen que SQLite3 no es multiconcurrente, acabo de hacer otra prueba, aun mas extensa.

1. Misma base de datos anterior que contiene dos tablas: Pais y Pais1.
La tabla Pais ya existe, con la data original de todos los paises (ya explicado antes) y es unica que se usa en esta prueba. La tabla Pais ya contenia 239 renglones, uno para cada pais.

2. Una aplicacion que manda los comandos que se le carguen, se abre dos veces, en dos instancias: App1 y App2

3. Se le carga a ambas el MISMO set de commandos SQL. Este set carga los 239 paises del planeta, con sus respectivas estadisticas, ya descritas.

4. Esta es una tira tipica de las 239 tiras del set:
INSERT INTO "country" VALUES('GUM','Guam','Oceania','Micronesia',549,NULL,168000,77.8,1197,1136,'Guam','US Territory','George W. Bush',921,'GU');
I
5. Amartillo las dos aplicaciones de tal manera que los botones de App1 y App2 de mando estan a un centimetro de separadas y el tiempo en presionar el boton de mando en App1 y App2 es minimo.

6. Como ahora no se crean tablas, y la tabla permite cargar duplicaciones, nada me impidio que me diera vuelo en presionar App1 y App2 alternandolos MUCHAS VECES y SIN LIMITE ALGUNO que el de mi rapidez y en unos cuantos ciclos la tabla Pais tiene ya 30,000 paises apx. Ni una sola de las veces rechino ni salio mensaje que me impida repetir esto hasta el cansancio.

No conte los cliks que di, pero dividiendo me resultan 125 transacciones A LA MISMA TABLA Pais que SQLite3 recibio correctamente, sin chistar.

Como ven, a SQLite no le importa a cual tabla le envien el grabado, siempre y cuando la data que se le mande sea correcta.

P.S. Me tarda mas escribir este mensaje que hacer las pruebas. SQLite3 todavia me esta esperando para que les siga picando el boton a App1 y App2, pues todavia las tengo preparadas y les puedo seguir picando los botones. Mas la verdad es que no le veo el caso. Para mi esto es concurrente y multiusuario. Que haya mas capacidad que esto, no lo niego.