Tamaño de Campo

judoboy · #1 18-07-2003

Sería una barbaridad guardar un campo varchar (6000) o lo puedo
hacer "tranquilamente"

__cadetill · #2 18-07-2003

Quizas mejor un campo de tipo Blob?

Iván · #3 18-07-2003

Para mi sería una barbaridad. Mejor como te dice un tipo blob, subtipo texto.

Un varchar como máximo debería ser de 255 carácteres.

Un saludo.

kinobi · #4 18-07-2003

Hola,

yo no soy tan categórico como mis compañeros. Los VARCHAR tienen un tamaño máximo de 32 Kb y en ocasiones pueden ser más eficientes y tener más ventajas que el uso de BLOBs.

Este artículo de Ivan Prenosil da algunas pistas para inclinarse por uno u otro:

http://www.volny.cz/iprenosil/interb...ib_strings.htm

Saludos.

judoboy · #5 18-07-2003

Gracias por las respuestas.

Por cierto esta interesante el artículo.

jachguate · #6 21-07-2003

Yo creo que en ocasiones conviene tenerlo en un varchar. Te recomiendo que crees la base de datos, eso si, con un tamaño de página adecuado para que por lo menos, un registro permanezca siempre en una sola página de la bd.

Hasta luego.

kinobi · #7 21-07-2003

Hola,

Cita:

Posteado originalmente por jachguate
Te recomiendo que crees la base de datos, eso si, con un tamaño de página adecuado para que por lo menos, un registro permanezca siempre en una sola página de la bd.

aunque es un buen consejo, en la práctica es algo bastante difícil de conseguir, al menos en todos los casos.

InterBase, como la mayoría de los gestores de bases de datos, divide su espacio de almacenamiento en diferentes zonas, dedicadas en general a diversas funciones: datos, índices, generadores, ... Las páginas de datos, a su vez, dependiendo de la actividad y volatilidad de la información, generan diversos "deltas" de los registros, necesarios para la implantación del sistema multigeneracional de registros. A su vez, la propia fragmentación interna de las páginas es resuelta por un proceso interno del servidor que compacta el espacio. Por último, tenemos el asunto de los tipos de datos no estructurados, como los BLOB's, que, debido a su tamaño no predefinido, pueden ser almacenados en la misma página de la fila a la que pertenecen o en páginas especiales para BLOB's, lo que echaría por tierra la correspondencia 1 fila en 1 página.

Saludos.

jachguate · #8 21-07-2003

Me referia por supuesto, al caso que utilices Varchar's. En el caso de los blob's, es natural que puedan ocupar una o muchas páginas del archivo.

Quizas peco de ignorante, pero en cuanto a la arquitectura multigeneracional, entiendo que (al menos hasta la versión 6 de ib y 1 de fb) no se crean deltas, sino copias enteras de los registros, con lo que la idea de mantenerlo en una página sigue siendo válida.

Al caber un registro de esta tabla en una página, y suponiendo que sería la tabla con el máximo requerimiento de espacio por registro, las páginas de datos de otras tablas, páginas de indices, etc. acomodarian perfectamente uno o varios registros.

hasta luego.

kinobi · #9 21-07-2003

Hola,

Cita:

Posteado originalmente por jachguate
Quizas peco de ignorante, pero en cuanto a la arquitectura multigeneracional, entiendo que (al menos hasta la versión 6 de ib y 1 de fb) no se crean deltas, sino copias enteras de los registros, con lo que la idea de mantenerlo en una página sigue siendo válida.

Hasta lo que yo sé, tanto antes como después de la versión 6 (que yo sepa no ha habido cambios al respecto), la multiversión de registro en InterBase (y Firebird) se basa en la creación de "deltas", sólo se almacenan los cambios efectivos dentro del registro y nunca copias completas, así como las referencias a registros eliminados. El motor crea una lista (enlazada) de "deltas" asociados a su identificador de transacción, de forma que se garantice el aislamiento entre transacciones.

Cita:

Posteado originalmente por jachguate
Al caber un registro de esta tabla en una página, y suponiendo que sería la tabla con el máximo requerimiento de espacio por registro, las páginas de datos de otras tablas, páginas de indices, etc. acomodarian perfectamente uno o varios registros.

cierto, pero convendrás conmigo que, debido a los argumentos a los que he hecho referencia en el mensaje anterior, no es una correspondencia exacta. En todo caso, en mi opinión, el tamaño de página debe ser elegido teniendo también en cuenta otros factores no menos importantes; por ejemplo el tamaño de bloque (o cluster) que el sistema de archivos del sistema operativo mueve entre disco y memoria principal. Desde este punto de vista, un tamaño de página óptimo en un determinado sistema de archivos puede no tener la misma eficacia en otro(s).

Saludos.

jachguate · #10 21-07-2003

Que tal Kinobi.

Tenes toda la razón con respecto de los otros factores a tomar en cuenta para elegir el tamaño de página.

La verdad me toma por sorpresa lo de los deltas, no cabe duda que cada día se aprende algo nuevo y me doy cuenta que puedo estar errado desde hace mucho. La verdad hace tanto que ya no recuerdo de donde saque la idea de las copias completas. Ya lo revisaré.

Hasta luego

kinobi · #11 21-07-2003

Hola Juan Antonio,

Cita:

Posteado originalmente por jachguate
La verdad me toma por sorpresa lo de los deltas, no cabe duda que cada día se aprende algo nuevo y me doy cuenta que puedo estar errado desde hace mucho.

En este artículo de Bill Todd en la Community Borland, tienes una referencia al respecto:

"When an update transaction commits, the database software checks to see if there are transactions with lower transaction numbers that are still active. If so then a new version of the record is created which contains the updated values. Each version also contains the transaction number of the transaction that created it. Note that Interbase does not create a complete copy of the row. Instead it creates a difference record that only contains the fields that were changed."

El artículo completo puede verse en:

http://community.borland.com/article...,27007,00.html

Saludos.

jachguate · #12 21-07-2003

El artículo está muy interesante. Gracias.