Y que se me suben hasta el cogote

[Casimiro Notevi]

La arqutectura multi generacional. Firebird maneja varias versiones para un mismo registro al mismo tiempo, para que cada transacción tenga su propia versión, su propia "imagen" de la realidad. Así es posible, por ejemplo, poder leer siempre sin "molestar" a los que escriben. Y los que escriben no molestan a los que leen.
Ejemplo básico: alguien hace una actualización (update) de un registro y otra persona está leyéndolo (select), pues hasta que el que está actualizando no confirme los cambios (commit), el que está leyendo seguirá viendo lo que había hasta que el otro confirme.
Es por lo que cada vez que se realiza cualquier acción sobre la base de datos, esta va creando registros "imágenes" de la "realidad" justo en ese momento, de esa forma no es necesario, por ejemplo, bloquear registros, ya que cada uno tiene una imagen del momento en que realiza cualquier acción.
Existe un mecanismo que cada cierta cantidad de registros que ya no sirven se deshace de ellos, aunque es configurable para ponerlo a más o menos registros, incluso para deshabilitarlo y sólo se realizará cuando nosotros lo queramos.

Por eso decía que no es ningún problema, simplemente funciona asi, y no importa que crezca la base de datos, toda la vida ha sido así, siempre ha funcionado así, es una de las características que tiene firebird, la MGA (multi generational architecture). Y que otros han copiado.

[[newtron]]

Empezado por Casimiro Notevi

Existe un mecanismo que cada cierta cantidad de registros que ya no sirven se deshace de ellos...

Entonces imagino que el tema de la "basura" no debería de preocupar al administrador de la base de datos porque ella misma se va limpiando, ¿no?. Te pregunto porque veo que es habitual entre muchos usuarios de FB el hacer y restaurar copia de seguridad para eliminarla.

[Casimiro Notevi]

Exacto, se elimina automáticamente y el espacio desocupado se reutiliza para nuevos registros.
Cuando se hace backup/restore se eliminan también y no se restauran.
Es configurable, por defecto "limpia" cada 20.000, pero puedes poner el valor que quieras, o deshabilitarlo y hacerlo cuando tú quieras.
Para contestar a tu pregunta: no tienes que hacer nada, no hace falta un administrador que se preocupe de eso, es automático. Nunca jamás me he preocupado por ese asunto, ningún cliente se ha preocupado nunca por eso. Lo más que recuerdo es que alguien diga:
Oye, que la base de datos crece mucho
¿Y cuánto mide ahora?
Ocupa 0,7 Gb.
¿Y De cuánto es el disco?
De 500 Gigas
Bien, pues todavía puede crecer 700 veces ese tamaño
¿Entonces no me precoupo?
Preocúpate de vender y ganar dinero para pagarme a mí

[roman]

Empezado por Casimiro Notevi

Ejemplo básico: alguien hace una actualización (update) de un registro y otra persona está leyéndolo (select), pues hasta que el que está actualizando no confirme los cambios (commit), el que está leyendo seguirá viendo lo que había hasta que el otro confirme.

Pero no me queda claro. ¿Qué pasa si lo que la segunda persona está leyendo es la existencia de un producto y vende algo cuando el primero actualizó diciendo que ya no había de ese producto? Es decir, no me queda claro como se evitan los bloqueos.

// Saludos

[[RONPABLO]]

Yo he tenido clientes donde se ha dañado la base de datos firebird, he identificado que ha ocurrido en en dos casos muy puntuales, una vez fue por un daño eléctrico del equipo y la otra vez fue por un mal manejo de copias de seguridad, ya que copiaban con un "control c" "control v" en caliente la base de datos, a tambien otra vez que trataron de abrir con word el archivo .fdb

[[Al González]]

Empezado por RONPABLO

[...] tambien otra vez que trataron de abrir con word el archivo .fdb

Ya veo al usuario con el "documento" abierto, presionando Ctrl+Fin y agregando las ventas del día.

Empezado por roman

Ya en delphi, ¿como se maneja esto? ¿Con un evento OnPostError? ¿O cómo?

En el caso de usar el juego de clases dbExpress-TDataSetProvider-TClientDataSet, los errores emitidos por el motor de base de datos pueden ser manejados en el evento TDataSetProvider.OnUpdateError, o bien en el evento TClientDataSet.OnReconcileError.

Esto sucederá al enviar los registros al servidor, y éste encontrar algún problema que impida guardar los cambios.

Código Delphi [-]
CDS.ApplyUpdates (0)

Cabe mencionar que ApplyUpdates no se rompe por la excepción generada, siempre devuelve un entero que indica la cantidad de registros que no pudieron ser "aplicados" a la base de datos.

Bueno, pero no asustemos al amigo AzidRain con historias de sucesos extraños. Aunque personalmente no he llegado por el momento a manejar en Firebird la cantidad de registros que él menciona, lo cierto es que los testimonios sobre Firebird en la Red son bastante alentadores. Así que el manejo de cientos de miles o millones de registros no debe representar problema alguno para este motor, siempre que se tengan los cuidados mínimos que se sugieren con cualquier base de datos.

Saludos.

Al González.

[[RONPABLO]]

Empezado por Al González

Ya veo al usuario con el "documento" abierto, presionando Ctrl+Fin y agregando las ventas del día.

....
....
Saludos.

Al González.

Pues ya me ha pasado varías veces que al ir a la carpeta donde tengo el programa instalado lo veo con la opción para abrir o con word o con acrobat reader... Me los imagino viendo la estructura del archivo y pensando... "esto debe ser la tal encriptación de la que hablan en las películas de computadores... "

[[newtron]]

Empezado por roman

Pero no me queda claro. ¿Qué pasa si lo que la segunda persona está leyendo es la existencia de un producto y vende algo cuando el primero actualizó diciendo que ya no había de ese producto? Es decir, no me queda claro como se evitan los bloqueos.

// Saludos

Eso eso, porque con esa filosofía y en este caso se venderá el artículo sin haber.

[Casimiro Notevi]

Empezado por roman

Pero no me queda claro. ¿Qué pasa si lo que la segunda persona está leyendo es la existencia de un producto y vende algo cuando el primero actualizó diciendo que ya no había de ese producto? Es decir, no me queda claro como se evitan los bloqueos.
// Saludos

Yo no sirvo de docente, me explico como un libro... cerrado, así que mejor copio aquí la parte que habla sobre ese tema en el famoso documento de Kinobi:

Empezado por Transacciones

Arquitectura Multi-Generacional
En entornos de bases de datos, el control de la concurrencia de múltiples usuarios
a los mismos datos se ha resuelto tradicionalmente con mecanismos de bloqueos[9].
Los bloqueos se basan en establecer una prohibición de acceso (bien de escritura, o
de escritura y lectura) sobre la información que queremos proteger. El bloqueo puede
hacerse a varios niveles: a nivel de tabla, el menos selectivo, ya que bloquea todos los
registros de la tabla; a nivel de página, bloqueando varias filas de una tabla, todas las
que entren en la(s) página(s) bloqueada(s); a nivel de registro, el más selectivo y menos
restrictivo de todos. El momento en que se establece el bloqueo determina su tipo:
pesimista, si se establece en el mismo momento que accedemos a los datos a proteger;
optimista, si se establece en el momento que realmente realizamos los cambios sobre
los datos a proteger. Los bloqueos han sido, y son, utilizados por muchos gestores de
bases de datos con éxito.
InterBase adopta23 otro enfoque para enfrentarse a la situación. Este enfoque es
el denominado multiversión de registro, llamado pomposamente ”Arquitectura Multi-
Generacional” (MGA) por Borland. La multiversión[10] se basa en generar nuevas
versiones de los registros ”tocados” por cada operación de modificación o eliminación.
23 InterBase no es el primer gestor de bases de datos que lo utiliza.

Cada vez que se inserta un registro en una base de datos InterBase se almacena,
junto con los datos, una referencia a la transacción a la que está asociada la operación
de escritura. A su vez, cada transacción que tiene lugar en la base de datos, sea de es-
critura o lectura, se asocia con un identificador, un número entero. Este identificador
sigue una secuencia ascendente, de tal forma que las transacciones más antiguas tienen
identificadores más bajos que las más recientes. Cuando se modifica un registro, se ge-
nera una nueva versión del registro asociada a la transacción que lo ha modificado. Esta
nueva versión mantiene un enlace24 a la versión antigua del registro y, recíprocamente,
la versión antigua mantiene un enlace a la nueva, formando una especie de cadena.
Cuando se genera la nueva versión del registro, se compara con la versión antigua para
generar un bloque con las diferencias encontradas, denominado BDR25 . Este registro
con las diferencias entre versiones se almacena en una nueva localización en la base
de datos, y la versión nueva del registro se sitúa en el lugar que ocupada la antigua
versión. De esta forma se garantiza que el versionado de registros sólo afectará a los
campos que se han cambiado realmente, de tal forma que no se almacena por cada
versión una copia completa del registro, sólo de los campos que hayan sido cambiados
por la operación de actualización. En las eliminaciones, el BDR almacena la versión
antigua del registro, mientras que la nueva versión simplemente almacena la referencia
a la transacción que eliminó el registro y una marca de borrado.
La ventaja fundamental del mecanismo de multiversión es que permite ”proteger”
un registro sin necesidad de bloquear explícitamente el acceso al mismo. Los redactores
no impiden el acceso a los lectores, y a otros redactores sólo lo hacen en el caso de
cambios en el registro. Veamos un ejemplo:
Supongamos que hemos abierto una transacción con identificador 100 (desde ahora
t100), con la intención de modificar (update) un registro. Otro usuario, antes de apli-
car nuestros cambios al registro, inicia una transacción (t101) con el mismo objeto.
Este usuario es más rápido y aplica sus cambios antes de que lo hagamos nosotros;
su transacción (t101) se termina y queda confirmada. En la práctica esto significa que
la versión más moderna del registro tiene el identificador de la transacción t101. Pos-
teriormente, nosotros intentamos aplicar nuestros cambios y nos encontramos con un
mensaje de error del servidor, indicándonos la imposibilidad de llevar a cabo la modi-
ficación, debido a que el registro ha sufrido una alteración desde el inicio de nuestra
transacción. A esta conclusión se llega comparando nuestro identificador de transac-
ción (t100), que es menor que el indetificador de la transacción de la última versión
del registro (t101). Sin haber utilizado un bloqueo explícito del registro, la transacción
t101 ha conseguido proteger sus cambios, incluso ante una transacción iniciada con
anterioridad a ella misma. Solución: nuestra transacción (t100) debe cerrarse e iniciar
una nueva (t102) para poder aplicar sus cambios.
Las reglas[10] que siguen el comportamiento de la concurrencia visto en el ejemplo
anterior son:
Si el identificador de la transacción es menor que el indetificador de la transac-
ción de la última versión del registro, entonces la transacción no puede ver o
modificar el registro.
Si el identificador de la transacción es igual que el indetificador de la transac-
ción de la última versión del registro, entonces la transacción sí puede ver y/o
modificar el registro.
24 Puntero.
25 Back Difference Record.

Si el identificador de la transacción es mayor que el identificador de la tran-
sacción de la última versión del registro, y además esta última fue confirmada
(commit) antes de que la transacción comenzará, entonces ésta sí puede ver y/o
modificar el registro.
Siguiendo el mismo razonamiento deducimos el mecanismo empleado para dar soporte
a los diferentes niveles de aislamiento de las transacciones. Este se basa en comparar
el identificador de nuestra transacción con el de las transacciones de cada una de las
versiones de los registros. En función de que sean menores, iguales, o menores, del
estado en el que se encuentren (obtenido de las páginas TIP), y el nivel de aislamiento
de nuestra transacción, se podrá acceder a unas, u otras, versiones de cada uno de los
registros.
Las características vistas hasta ahora en el mecanismo de multiversión son realmen-
te interesantes, y constituyen un método elegante y eficaz para resolver el problema de
la concurrencia de múltiples usuarios y los diferentes niveles de aislamiento de las tran-
sacciones en bases de datos InterBase. ¿ Demasiado bonito para ser verdad ? ... cierto,
la multiversión también tiene su lado oscuro, y está precisamente ahí, en la generación
de múltiples versiones de los registros. Aunque hemos visto que en cada nueva versión
de un registro sólo se registran los cambios reales aplicados, estas nuevas versiones
pueden llegar a ocupar mucho espacio innecesariamente, además de someter a los pro-
cesos que acceden a la base de datos a una sobrecarga al tener que recorrer las cadenas
de las versiones de cada registro, seguramente muchas de estas versiones ya obsoletas.
Esta basura que genera el mecanismo de multiversión es responsable de una pérdida
gradual del rendimiento en el acceso a la base de datos, que debe ser recuperada a
través de mecanismos de limpieza, como veremos en la siguiente sección.

[roman]

Gracias Creo que ya lo veo más claro. Con el MGA se maneja en automático el bloqueo optimista: pensar que no va a pasar nada, y si pasa ya me lo avisa después anulando mis cambios.

Ya en delphi, ¿como se maneja esto? ¿Con un evento OnPostError? ¿O cómo?

// Saludos

[ecfisa]

Ya en delphi, ¿como se maneja esto? ¿Con un evento OnPostError? ¿O cómo?

Si mas o menos así. Existe la declaración POST_EVENT, que puede usarse para ese fin.

Saludos.