Indices
La base de datos Velneo tiene algunos automatismos realmente interesantes, uno de ellos es la creación automática de los enlaces plurales, este subobjeto es totalmente dinámico y se crea en tiempo de ejecución en base a los índices existentes en las tablas, de tal forma que si las primeras partes de un índice coinciden con el índice ID de una tabla maestra se crea automáticamente el subobjeto enlace plural. Este subobjeto permite navegar por la información desde la tabla maestra a su plural.
Además de la navegación desde el maestro a su plural este subobjeto permite el funcionamiento a otro automatismo de la base de datos, el despliegue del cambio de código del maestro a sus plurales. Es decir, si un maestro tiene el código 100 y por algún motivo necesitamos ponerle el código 200, al hacerlo la base de datos de Velneo se encarga de cambiar el código en todas las tablas plurales que apuntan a este registro maestro.
Para que el cambio de código funcione bien y no nos llevemos ninguna sorpresa es necesario que existe un enlace plural. Por este motivo es fundamental que creemos siempre un índice en la tabla plural a través del campo puntero a maestro, en el caso de las tablas submaestras el índice tiene varias partes pero el funcionamiento es similar. Este índice se crea automáticamente cuando creamos el campo puntero a maestro con las herramientas del editor de esquemas o con el selector de tabla maestro en el editor de tabla. Si añadimos el campo manualmente o copiando de otro campo debemos tener la precaución de crear el índice.
Debemos tener en cuenta que en muchas ocasiones tenemos índices condicionados, es decir que indexan a través del campo puntero a maestro pero solo indexan algunos registros, los que cumplen la condición. Esto debemos tenerlo presente ya que en ese caso el cambio de código solo se aplicaría en los registros que cumplen la condición, pero nos quedarían otros registros con el código antiguo lo que supondría un gran problema. Por ejemplo, si tenemos la familia A100, y en la tabla de artículos solo tenemos un índice por familia que indexa los que tienen existencia. Si cambiamos el código de la familia a B200, solo se cambiaría en los artículos con existencia, quedando erróneamente otros artículos con el código de familia A100, que en caso de ser reutilizado supondría tener una base de datos errónea. Por este motivo, si tenemos que crear índices condicionados es conveniente también tener un índice al maestro sin ninguna condición, es decir que indexe todos los registros.
Es cierto que no es habitual cambiar los códigos ID de las tablas maestras, y en muchos casos ese dato ni se visualiza en pantalla ni se deja cambiar al usuario, pero en una base de datos existen muchas tablas con circunstancias "especiales", por ejemplo tablas cuyos registros nacen de la importación de información de otro sistema o que son claves que cambian con el tiempo.
Lo más recomendable en Velneo es crear siempre la tabla maestra con el campo ID y añadir otros campos de códigos externos que pueden cambiar, pero dejando siempre como enlace entre el maestro y sus plurales a través del ID que genera Velneo. Esto es lo más habitual y recomendable, porque aunque los artículos tengan referencias o códigos de barras y los clientes tengan un CIF o un DNI siempre será más óptimo indexar y apuntar a tablas del campo ID numérico que tendrá un máximo de 4 bytes. De esta forma ganamos espacio y rendimiento.
Si en alguna tabla, por ejemplo de tipo arbolada, necesitamos usar códigos que nos vienen dados por terceros, debemos tener en cuenta lo comentado en el punto anterior sobre tener siempre índices en las tablas plurales sin condicionar que nos aseguren que cualquier cambio en el código del maestro se aplicará en todos sus plurales.
En tablas grandes con muchos campos y muchos índices hay que tener especial precaución con los índices que se crean ya que es muy fácil crear índices "duplicados" si no tomamos medidas para evitarlo.
¿Qué es un índice duplicado? Obviamente el primer caso de índices duplicados es aquél en que ambos índices son exactamente iguales, pero también podemos considerar que un índice está duplicado cuando sus partes coinciden con las primeras partes de otro índice. Veamos un ejemplo.
Es muy habitual que a medida que va creciendo el proyecto se vayan creando nuevos índices, en el ejemplo anterior es posible que inicialmente se haya creado el índice ART_EMP con esas 2 partes y posteriormente se creó el índice ART_EMP_ALM con 7 partes, si el responsable de base de la base de datos no tiene cuidado quedarían los 2 índices creados cuando realmente no es necesario ya que podemos utilizar el índice ART_EMP_ALM buscando por parte izquierda resolviendo solo el artículo y empresa, obteniendo de esta forma el mismo resultado que si usamos el índice ART_EMP. Cuando encontremos un caso de estos nos quedaremos con el índices de más partes y refactorizaremos los objetos que usaban ART_EMP para que usen ART_EMP_ALM por parte izquierda o incluso también se puede usar entre límites.
La mejor forma de evitar tener índices duplicados es poner buenos identificadores a los índices para que expresen bien sus partes y organizar los índices de las tablas por orden alfabético. De esta forma detectamos fácilmente las duplicidades de un vistazo, como se puede apreciar en la siguiente captura.
Es evidente que ver un índice ART_EMP al lado de otro que se llamada ART_EMP_ALM es un claro indicativo de que puede haber una duplicidad, aunque podría darse la circunstancia de que tengan diferente condición de indexación, algo que debería reflejarse en el identificador.
Los índices condicionados son una gran herramienta para el programador. En principio su uso es totalmente aconsejable ya que con ellos mejoramos el rendimiento de nuestras aplicaciones al evitar búsquedas más complejas o filtrados.
Es cierto que el tiempo de indexación de un índice condicionado es aproximadamente un 30% superior a un índice sin condicionar, al tener que evaluarse la fórmula de la condición, pero este tiempo además de que solo nos penaliza una única vez en el alta, baja o modificación, es muy pequeño, por lo que podemos asumirlo sin ningún problema dadas las ventajas que nos aporta.
Siempre que tengamos estados de registros, los índices condicionados son un gran aliado ya que podemos obtener de forma directa los registros adecuados ordenados en función de las partes definidas. Sin duda alguna una herramienta a tener en cuenta y usar de forma constante.
Hay dos casos en los que no merece la pena crear índices condicionados:
- 1.Si un índice condicionado solo se usa una vez al año para un informe concreto, no tiene mucho sentido crear en la tabla un índice que estará infrautilizado para ganar unos segundos en un informe que apenas se utiliza.
- 2.Si tengo decenas de estados, en lugar de crear decenas de índices condicionados tiene más sentido crear un índice por el campo estado y buscar de forma directa un estado.
El tamaño de un índice viene dado por la suma de tamaño de las partes que lo componen, sin embargo en un índice de tipo acepta repetidas debemos tener en cuenta que Velneo añade 4 bytes al tamaño del índice. Esto lo hace porque aunque acepte claves repetidas la base de datos necesita poder apuntar a cada registro de forma única. Al añadir 4 bytes Velneo permite hasta 4.000 millones de repeticiones de una clave. Es decir que aunque para nosotros a nivel de programación se aceptan claves duplicadas, internamente se comporta como si fuese un índice de clave única, aunque nosotros como programadores nunca veremos los 4 bytes adicionales que componen el índice.
A la hora de regenerar una tabla o indexar alguno de sus índices podemos observar que los índices de clave única son más rápidos en estas operaciones que los de acepta repetidas, lógicamente en este proceso influye lo comentado en el apartado anterior del control de claves repetidas. Además, cuanta menos repetición de claves tengamos más rápido se indexa un índice.
En un índice acepta repetidas el orden de los registros vendrá dado por el orden de creación de dicho registro, este comportamiento puede ser deseado o no. En caso de que queramos garantizar un orden específico conviene añadir más partes a nuestro índice, intentando siempre en la medida de los posible crear el índice con el menor tamaño posible. Por ejemplo, en la tabla de facturas podemos crear un índice por el cliente de tipo acepta repetidas, pero puede ser mucho más interesante crearlo con las partes cliente y fecha, de esta forma cuando carguemos plurales de facturas del cliente nos aparecerán ordenadas por fecha, si además en el índice añadimos el ID o el número de la factura y podemos poner el índice de tipo clave única, además de ser un índice más rápido para la reindexación conseguiremos que en caso de que un cliente tenga más de una factura en la misma fecha salgan ordenadas por número.
En definitiva, que es más recomendable tener índices de clave única para lo cual en las tablas maestras siempre podremos conseguirlo de forma sencilla añadiendo el ID como última parte del índice.
Cuando tenemos que indexar un campo alfabético con un tamaño grande (>50 caracteres) puede ser muy buena opción aplicar una indexación parcial. Salvo que sea necesario indexar de clave única, podemos utilizar la propiedad longitud para reducir el tamaño del índice.
En el ejemplo anterior vemos como al especificar la propiedad longitud en el campo NAME nos permite reducir el tamaño del índice a 12 bytes. De esta forma solo se indexarán los primeros caracteres del campo, algo que en la mayoría de las ocasiones no supone ningún problema ya que no es habitual que coincidan, y en el caso de que coincidan estarían juntos en la lista.
Por otro lado la propiedad conversión nos permite indicar que aunque el campo sea de tipo Alfa 256, a la hora de indexarlo, en el índice se indexe como Alfa 128, Alfa 64 o Alfa 40 consiguiendo de esta forma que se puedan encontrar los registros tanto en minúsculas como en mayúsculas y sobre todo que con una longitud de 12 bytes en el índice estemos indexando por los 18 primeros caracteres del campo NAME.
Sin duda son los índices más potentes de la base de datos de Velneo, su gran virtud es la potencia de búsqueda su mayor problema es el tamaño en disco y la reindexación. Por este motivo hay que equilibrar su uso.
En tablas con pocos registros no hay ningún problema generar ambos índices, pero en tablas con millones de registros tenemos que tratar de evitar que el índice nos cause problemas de rendimiento, en algunos casos puede ser conveniente generar solo el índice por palabras ya que es mucho más reducido que el de trozos, pensemos que la palabra “Amortiguador” generaría una única entrada en el índice de palabras, pero 10 entradas (Amo, mor, ort, rti, tig, igu, gua, uad, ado, dor) en el índice por trozos, lo que supone una gran ocupación en disco y un mayor tiempo de reindexación.
Debemos evitar siempre crear, siempre que sea posible, varios índices de trozos y palabras. Es decir, no tiene sentido crear el índice por palabras para el campo nombre y otro índice por palabras para el campo dirección, en ese caso debemos crear un único índice por palabras añadiendo ambos campos como partes del mismo índice, además de tener menos índices lo que mejora el tiempo de reindexación ya que solo se lee el registro una vez para reindexar ambos campos sino que además nos permite que el usuario busque por cualquier de los dos datos a la vez sin tener que pedirle dos datos en pantalla o tener que hacer 2 búsquedas y cruzarlas.
Hay que tener en cuenta que podemos incluir en los índices por trozos y palabras campos de tipo objeto texto y objeto texto enriquecido, en este último caso Velneo se encarga de quitar las etiquetas HTML e indexar solo el contenido del campo. Debemos ser precavidos a la hora de indexar este tipo de campos por trozos o palabras ya que el número de entradas en el índice puede ser gigantesco dependiente de lo que grabemos en dichos campos ya que debemos recordar que son de longitud variable y si el usuario quiere puede meter en un campo el contenido de un libro. Además de la ocupación en disco, dar de alta un registro que tenga que indexar un gran volumen de palabras o trozos de palabras puede suponer un retardo que produzca una mala experiencia para el usuario.
Este tipo de índice como su nombre indica es un objeto sencillo de definir pero con una funcionalidad realmente compleja que resuelve casos que requieren mucha programación o que gracias al uso de este tipo de índice se consiguen unos rendimientos que no podemos alcanzar mediante programación.
Es muy importante tener en cuenta que aunque los índices complejos se reindexan automáticamente al cambiar las partes tienen el hándicap de que no se indexan la primera vez que se crean, algo que debemos tener en cuenta si creamos un índice complejo sobre tablas que contienen datos. Una buena práctica consiste en crear el código necesario para forzar su indexación inicial cuando instalamos la versión de nuestra aplicación.
Poder indexar registros de una tabla por datos que se encuentran almacenados en otras tablas nos ayuda a reducir el tamaño de las tablas al no tener que duplicar información redundante para poder indexarla, nos evita programación adicional para reflejar los cambios de datos en la tabla donde queremos indexar, sin embargo, también tiene como pro que regenerar índices complejos de tablas grandes va a requerir tiempo y puede que mucho espacio en disco, en función del tamaño de las partes a indexar.
Ejemplos típicos de índices complejos son:
- Indexar contactos por sus direcciones, teléfonos, emails.
- Indexar ventas por las palabras del artículo.
- Indexar facturas por los trozos del nombre del cliente.
Por este motivo hay que tener precaución a la hora de generar índices complejos de tablas con millones de registros con un índice por trozos o palabras ya que estaríamos creando un índice enorme en tamaño y con un tiempo de reindexación muy elevado. Esto no quiere decir que no podamos crear un índice complejo por trozos o palabras del nombre del artículo indexando las líneas de venta, pero sí debemos tener en cuenta el tamaño y la ocupación para decidir si por ejemplo solo lo generamos por palabras que será mucho más pequeño que si lo hacemos por trozos.
Última actualización 3yr ago