Comment on page
Campos
A continuación se detalla en una tabla el uso recomendado de campos de tipo alfabético.
- Alfa 256: almacenar campos alfanuméricos permitiendo todo tipo de caracteres y longitud específica.Hay que tener en cuenta que aunque soporta hasta 65.535 caracteres no tiene mucho sentido guardar tanta información en un campo de este tipo, siendo recomendable usar campos objeto texto o texto enriquecido en su lugar.
- Alfa 128: para guardar datos alfanuméricos como nombres, direcciones, etc.Hay que tener en cuenta que no soporta todos los caracteres ASCII por lo que debemos evitar usarlo para almacenar URLs o eMails por ejemplo, en ese caso es mejor usar el Alfa 256.
- Alfa 64: para guardar datos alfanuméricos en mayúsculas independientemente de como los escriba el usuario. Se usa para guardar textos en mayúsculas, referencias o códigos que usan caracteres no soportados en los Alfa 40.
- Alfa 40: muy recomendable para códigos alfanuméricos, referencias, código de barras, etc.Hay que tener en cuenta que el tamaño mínimo siempre debe ser múltiplo de 2 y que su contenido que se puede grabar en el campo será múltiplo de 3, es decir, que si quiero poner en un formulario un campo para guardar 4 caracteres este tipo de campo puede no ser óptimo.
- Alfa Latin1: cuando el contenido del campo debamos enviarlo a un servicio o software externo que tenga ese requisito de codificación. También podemos resolver la codificación en el momento de la exportación, por este motivo no es habitual usar este tipo de campo.
- Alfa UTF-16: cuando tengamos que incluir contenido en idiomas de doble byte como el Chino. Hay que tener en cuenta que estos campos ocupan el doble que uno normal, por lo tanto no debemos poner los campos de las tablas de este tipo si creemos que en el futuro instalaremos una versión para usuarios en Chino ya que estaremos perjudicando el tamaño de la base de datos y el rendimiento por algo que puede no llegar a concretarse nunca. Es preferible que llegado el momento hagamos el cambio de tipo de los campos ya que la refactorización automática hará que el cambio no produzca ninguna pérdida de datos.
No, realmente el campo Alfa 256 es el más rápido en su uso debido a que su contenido se procesa de forma directa, sin embargo los Alfa 128, Alfa 64 y Alfa 40 utilizan datos comprimidos a nivel de bits. Realmente el proceso de compresión y descompresión es muy rápido pero a la hora de realizar miles o millones de operaciones con cadenas es preferible el uso de campos Alfa 256.
Sí, esa es su función, pero debemos tener en cuenta que el campo admite hasta un máximo de 24 horas (un día), por lo tanto si queremos almacenar tiempo superior a un día debemos utilizar un campo numérico donde guardemos los segundos, minutos u horas según el caso y luego utilizar campos para convertir esos tiempos a horas:minutos:segundos.
Los campos fórmula son muy recomendables para ahorrar espacio en el tamaño de registro, ya que su ocupación en disco es cero.
Debemos tener en cuenta que la fórmula se calcula allí donde se solicita el valor del campo, por ese motivo si vemos que queremos hacer un uso intensivo de ese campo en rejillas o si hay muchas dependencia de contenidos iniciales como puede ocurrir en tablas de estadísticas con acumulados mensuales (saldos, existencias, estadísticas, etc.) podemos optar por utilizar campos con persistencia en disco, que aunque ocupan espacio y aumentan el tamaño del registro, evitan el recálculo del dato ya que se calcula una única vez a través o bien del contenido inicial, de algún evento de tabla o directamente en código del objeto visual, y nos ahorra volver a calcular en el momento en que se muestra el datos en un informe, rejilla, formulario, etc.
Los campos objeto tienen una ocupación en el registro de 8 bytes en los que se almacena la referencia al primer bloque de 512 bytes del contenedor de objetos. En el contender todos los contenidos sean texto, imágenes o ficheros se almacenan en celdas de 512 bytes, cuando un objeto ocupa más de 512 bytes va ocupando más celdas de este tamaño hasta almacenarse en su totalidad, todas las celdas de un objeto quedan relacionadas e indexadas para un rápido acceso.
Por lo tanto tenemos que tener claro que si vamos a almacenar un texto con un tamaño fijo menor de 512 bytes, a priori podríamos pensar que un campo alfabético será más recomendable, sin embargo eso dependerá del número de registros que estén ocupados. Si por ejemplo creamos un campo de 100 bytes que solo es ocupado en el 10% de los registros de una tabla que tiene 1.000.000 de registros, estaríamos ocupando 100 MB de disco de los que el 90% estaría vacío. Sin embargo, si usamos un campo objeto tendríamos 8 MB de ocupación de los 8 bytes del campo más 100.000 celdas de 512 bytes lo que daría un total de 520 MB, es decir, la mitad de ocupación en disco más la ventaja de que el registros es 92 bytes más ligero. Aunque no supone ningún inconveniente tenemos que tener claro que la carga de objetos se realiza en hilos secundarios ya que no viaja con la información del registro.
Otra característica muy interesante de la base de datos de Velneo es que puedes indexar por trozos y/o palabras los campos objeto texto y objeto texto enriquecido (en este caso la base de datos se encarga de eliminar las etiquetas HTML de la indexación). Esta es una característica muy potente, aunque hay que gestionarla bien ya que la indexación de textos largos pueden generar millones de entradas en el índice de los contenedores.
Existen diferentes circunstancias en las que el uso de objeto texto nos va a ayudar a optimizar la ocupación de espacio en la base de datos, y por lo tanto el rendimiento en ejecución de nuestra aplicación.
- Cuando la ocupación de registros es baja, por ejemplo <10% para tamaños de >100 bytes.
- Para evitar crear campos alfabéticos muy grandes (>100 bytes).
- Para almacenar contenido variable que puede ser de miles de KB o cientos de MB.
- Para evitar la creación de campos adicionales configurables. Se explica más abajo.
- Para almacenar contenido HTML usa el objeto texto enriquecido.
Aunque los objetos texto son muy cómodos de usar si lo que queremos almacenar es una gran cantidad de información como puede ser el caso de un gestor de documental en el que podremos almacenar cientos de miles de documentos de gran tamaño, el mejor planteamiento puede ser no utilizar campos objeto y en su lugar almacenar de forma externa los ficheros guardando en un campo del registro la senda o URL de acceso a dicho fichero.
Hacerlo de forma externa nos permite mayor flexibilidad a la hora de almacenar los ficheros clasificados y organizados en disco por carpetas, a la vez que minimiza el tamaño de nuestra base de datos lo que facilita su gestión y reindexación.
El único hándicap en este caso es que perdemos la posibilidad de indexar por trozos o palabras los textos, aunque se pueden usar alternativas como almacenar solo palabras claves en un objeto texto del registro que nos facilite la localización del fichero sin engordar nuestra base de datos con su contenido.
En ocasiones hay aplicaciones muy configurables que permiten a los clientes finales o usuarios añadir campos personalizados en algunas tablas. La base de Velneo es estática en cuanto a su definición, es decir, no podemos cambiar en tiempo de ejecución la estructura de una tabla añadiendo nuevos campos.
Para poder simular los campos personalizables se podría pensar en dejar creados, por ejemplo 3 campos alfabéticos de 50 caracteres, 3 campos numéricos y 3 campos de tipo fecha. Además de poco práctico ya que en un momento dado el usuario podría necesitar 4 campos de un determinado tipo y ninguno del resto supone un gran desperdicio de espacio en disco con múltiples campos vacíos.
En su lugar de puede optar por usar un campo objeto texto en el que almacenemos los contenidos de todos los campos con algún tipo de separador, por ejemplo:
- Formato XML. <nombre campo>Contenido del campo</nombre campo>
- Formato JSON. { "nombre campo" : "contenido campo" }
- Formato CSV. En la primer línea los nombres de campo “nombre campo 1"|"nombre campo 2"|"nombre campo 3" y en la 2ª línea los datos "contenido campo 1"|"contenido campo 2"|"contenido campo 3"
- Salto de línea. El nombre del campo estaría configurado en un campo objeto texto a nivel de aplicación o empresa y el contenido de los se guarda cada uno en una línea añadiendo un salto de línea después del dato.
De esta forma podemos almacenar múltiples valores en un único campo objeto texto. Evidentemente hay un trabajo de programación adicional para poder visualizar esta información de forma dinámica en un formulario o rejilla (usando una tabla en memoria, por ejemplo). Además, la indexación por los valores de estos campos de forma individual resulta más compleja.
Los contenidos iniciales de los campos se evalúan cuando damos el alta de un registro y cuando hacemos modificaciones de los datos del registro. Es un gran recurso para el programador y debemos usarlo con cuidado para no abusar de sus bondades perjudicando el rendimiento de nuestra aplicación.
Una de las grandes ventajas es que el valor de un campo se calcula automáticamente en base al de otros campos. Esta característica es buena siempre y cuando no abusemos de ella, es decir, si tenemos una tabla con cientos de campos y creamos unos contenidos iniciales muy dependientes entre sí de tal forma que cualquier cambio en un campo produzca el recálculo de muchas decenas o incluso un centenar de contenidos iniciales en otros campos podemos detectar lentitud en nuestra aplicación. Para evitar estos casos excepcionales podemos renunciar al contenido inicial y hacer los cálculos bien en el objeto visual en 1º plano o también en los triggers anterior al alta o modificación, evitando que se recalculen de forma constante y en su lugar conseguir que los cálculos solo se realicen una vez.
Cuando usamos hermanos contiguos en los contenidos iniciales debemos tener la precaución de evitar cálculos en cascada incontrolados. En principio esto no debería de producirse con contenidos iniciales ya que solo afectan al registro en curso, sin embargo sí que tenemos que tenerlo en cuenta si en lugar de un campo con persistencia en disco y contenido inicial usamos un campo fórmula que utiliza un campo obtenido a través de un puntero a un hermano contiguo, ya que en ese caso si el campo del registro apuntado a su vez es una fórmula que tira del hermano contiguo lo que estamos provocando es que el cálculo de un campo realiza lecturas y cálculos en un número de registros incontrolado que puede dar lugar a cálculos de miles de registros.
Para evitar estas circunstancias es preferible usar campos con persistencia en disco y contenidos iniciales o cuyo valor se calcula una única vez en un evento de tabla o proceso. Aunque tenemos mayor ocupación en disco a cambio obtener un mejor rendimiento de la aplicación.
Si tenemos una función que realiza un cálculo complejo que, por ejemplo requiere la lectura de múltiples registros, y usamos esta función en contenidos iniciales de campos debemos revisar que no afecta al rendimiento. Hay que tener en cuenta que los contenidos iniciales aunque están definidos en la tabla no siempre se ejecutan en el servidor, al dar el alta desde un formulario se ejecutan en 1º plano, y en el caso comentado puede producir lentitud en la apertura del formulario o la aparición del icono de espera cuando se esté ejecutando el cálculo del valor del campo.
Si además, a la función se le pasan como parámetros valores de otros campos, podemos encontrarnos con que la función se ejecuta múltiples veces al estar en un contenido inicial, para evitar esta circunstancia debemos evitar su uso en un contenido inicial moviendo la ejecución de la función a los eventos de tabla anterior a alta y modificación, o si la aplicación lo permite directamente en el objeto visual como puede un formulario de edición.
En los contenidos iniciales de los campos de una tabla podemos utilizar fórmulas de código Velneo y también fórmulas JavaScript. Debemos saber que cada vez que se ejecuta una fórmula JavaScript es necesario lanzar un motor de ejecución y alimentarlo con las clases generales para que disponga de la información del entorno, aunque esta operación es rápida en términos generales es lo suficientemente lenta como para notar retardo respecto al cálculo de fórmulas de código Velneo, por lo tanto debemos usar fórmulas JavaScript con la precaución de saber que solo se calculará una vez.
Si tenemos varios campos que necesitamos calcular con una fórmula JavaScript podemos optimizarlo no usando la fórmula en el contenido inicial y en su lugar ejecutarla en los eventos de tabla anterior al alta y modificación lanzando un proceso de código JavaScript de origen ficha. De esta forma aseguramos que se ejecute una única vez y además podemos calcular el valor de múltiples campos en el mismo script con lo que optimizar todos los cálculos en una única ejecución del motor de JavaScript.
Cuando estamos importando miles o incluso millones de registros en las tabla Velneo es habitual que los datos que estamos importando no requieran que se disparen los contenidos iniciales ya que nos llegan calculados.
Con el fin de optimizar la importación, debemos sustituir el uso del comando de instrucción “Modificar campo” por el comando de instrucción “Modificar campo solamente” que se encarga de modificar el valor del campo pero evitando que se disparen los contenidos iniciales. Si en algún momento necesitamos que se ejecuten los contenidos iniciales podremos forzarlo ejecutando el comando de instrucción “Calcula campos dependientes”, este comando se puede ejecutar múltiples veces antes de grabar el registro.
Última actualización 3yr ago