Supongamos que tienes un dominio y decides cambiarlo. Ese dominio quizás está siendo usado en muchas tablas, algunas de las cuales pueden tener millones y millones de filas.
No puedes cambiar un dominio para que guarde menos datos que antes, pero sí puedes cambiarlo para que guarde más datos que antes. Cambiar de INTEGER a SMALLINT no está permitido. Cambiar de SMALLINT a INTEGER sí está permitido. Cambiar de CHAR(10) a CHAR(2) no está permitido. Cambiar de CHAR(2) a CHAR(10) sí está permitido.
Así que veamos lo que ocurrirá cuando quieres cambiar un dominio y está permitido hacerlo.
Ejemplos:
D_PRECIO1 DECIMAL(9, 2) quieres cambiar a D_PRECIO1 DECIMAL(18, 2)
D_APELLIDOS VARCHAR(20) quieres cambiar a D_APELLIDOS VARCHAR(25)
¿Cómo actuará el Firebird en una situación así?
Cambiar cada fila de cada tabla que usa el dominio no es práctico, es totalmente improductivo, porque algunas tablas pueden tener millones y millones de filas y estar siendo usadas por cientos o miles de usuarios. Hacer algo así demoraría mucho tiempo y además podría causar un sinfín de problemas.
Por lo tanto, lo que el Firebird hace es lo siguiente:
- Cuando se cambia un dominio, no altera a ninguna columna de ninguna tabla. Todo sigue igual en las tablas que creó el desarrollador.
- Los que sí cambian son los metadatos, las estructuras de las tablas que usan ese dominio son cambiadas.
- Cuando se hace un INSERT, usa el nuevo dominio en la fila insertada
- Cuando se hace un UPDATE, usa el nuevo dominio en la fila actualizada (recuerda que cada UPDATE crea una nueva fila. Y en esa nueva fila se usará el nuevo dominio). La fila original no se toca, queda como estaba.
- Cuando se hace un SELECT, las filas que tienen el dominio viejo serán cambiadas en memoria para que tengan el dominio nuevo, así que al ver las filas obtenidas se las verá con el dominio nuevo. Las filas no son cambiadas en la Base de Datos, el cambio se hace solamente en la memoria RAM de la computadora del Servidor.
¿Es posible conseguir que todas las columnas de todas las tablas utilicen el nuevo dominio?
Sí. Usando GBAK para hacer un ciclo backup/restore la Base de Datos restaurada tendrá todas las columnas con el nuevo dominio.
GBAK hará que todas las columnas de todas las filas de todas las tablas estén estructuradas con los últimos dominios definidos.
Recuerda que la Base de Datos original no se cambia, queda como estaba, la que se cambia es la Base de Datos restaurada.
Conclusión:
El Firebird permite cambiar la definición de un dominio, si el nuevo dominio permitirá guardar más datos que el viejo dominio.
Cuando se cambia un dominio, se cambia la estructura de las tablas que usan ese dominio (es decir, los metadatos) pero no se cambian las filas que insertaron los usuarios. Esas filas quedan igual, no se tocan.
Cambiar las filas que insertaron los usuarios demoraría mucho tiempo y podría causar muchos problemas, sería una idea muy mala, por lo tanto el Firebird hace lo más inteligente:
Cuando se hace un INSERT, se usa el nuevo dominio. Cuando se hace un UPDATE, en la fila actualizada se usa el nuevo dominio. Cuando se hace un SELECT, las filas que tenían el dominio viejo se cambian en memoria para que tengan el dominio nuevo y así los usuarios puedan ver esas columnas con el dominio nuevo.
Si se desea que todas las columnas usen físicamente el nuevo dominio, hay que hacer un ciclo backup/restore usando el programa GBAK. Así, la Base de Datos restaurada tendrá a todas sus columnas estructuradas con los últimos dominios definidos.
Artículos relacionados:
Entendiendo a los metadatos del programador
La forma más fácil de cambiar un dominio
Jun 23, 2015 @ 20:31:58
Hola Walter, primero quiero agradecerte por la información que pones en tu blog, excelente. Por lo que he leído en tu blog, tu recomiendas que cada campo definido en las tablas tenga su correspondiente dominio, es importante esto ? Si no se usan dominios, tendremos algún tipo de inconveniente ? Nuevamente gracias….
Jun 24, 2015 @ 02:49:02
Víctor, que bueno que la lectura de los artículos del blog te resulte útil. Esa es la idea.
Lo peor que le puede suceder a una Base de Datos es que tenga basura. Se llama basura a cualquier dato que está pero que no debería estar. Si hay basura entonces ningún proceso y ninguna consulta serán confiables, sus resultados pueden ser cualquier cosa, menos lo que deberían ser. Eso es inadmisible. Y los culpables de que haya entrado basura son por lo menos en un 99% los informáticos.
El Firebird nos provee de seis herramientas para impedir la basura: los dominios, las primary keys, las foreign keys, las restricciones check, las unique keys y los triggers.
Esas herramientas existen para ser usadas.
Los dominios y las restricciones check son muy similares, la diferencia es que al definir un dominio lo podemos usar en cualquier columna de cualquier tabla, quizás lo usamos cientos de veces, en cambio las restricciones check son específicas de una columna y de una tabla.
Al definir un dominio lo que hacemos es acotar los valores que son aceptables de un tipo de datos estándar. Por ejemplo, nuestro tipo de datos estándar es DATE (o sea: fecha) y creamos un dominio llamado D_FECHA_VENTA que solamente admite fechas iguales o posteriores al 14 de octubre de 2012. ¿Por qué? porque la empresa fue creada en esa fecha y es por lo tanto imposible que haya vendido algo con anterioridad. Si nuestro tipo de datos estándar es SMALLINT y definimos un dominio llamado D_CANTIDAD_MINIMA que solamente admite valores mayores que cero, nos aseguraremos que nunca se registrará la venta de cero artículos o de un número negativo de artículos. Si la calificación de un alumno solamente puede estar entre 0 y 100, entonces si definimos un dominio de SMALLINT llamado D_CALIFICACION que solamente acepte valores entre 0 y 100 jamás un alumno tendrá una calificación fuera de ese rango.
No es necesario ni obligatorio usar dominios, si no los quieres usar pues no los usas y ya.
Pero están allí para ser usados y son una herramienta buenísima para impedir que entre basura.
No usar dominios implica al menos que:
a. Tendrás que usar muchas más restricciones check que las necesarias, o que:
b. La columna no tiene una restricción y por lo tanto admite alegremente que entre basura, y que:
c. Mirando la estructura de una tabla se te complica saber cuales valores son válidos en cada columna
Un buen diseñador de bases de datos, siempre, en todos los casos, sin excepción, usa dominios en todas las columnas de todas las tablas. Repito: en todas las columnas de todas las tablas. Siempre. Sin excepción.
Saludos.
Walter.
Jun 24, 2015 @ 11:29:40
Gracias Walter…