Respecto a PKs

Hola Alfredo:

En principio no hay ninguna razón por la que las PK tengan que ser
inmutables, pero si tu quieres que lo sean de todas formas por motivos
funcionales, entonces no le veo sentido a tener otro código cambiable.

Es una decisión que tomé después de tener problemas en otro proyecto
por usar columnas como PKs que sí se podían cambiar. Leí, o alguien me
dijo por ahí que la situación ideal es que no se cambiaran nunca las
PKs y decidí tener un campo ID y en si es necesario, otro campo código,
pero este a nivel de usuario.

Es un código irrelevante, no guarda información,

Entonces obviamente lo deberías eliminar.

es para otra cosa que
me va a costar explicar aquí.

Ya, con información incompleta no se puede aconsejar.

No guarda información pero sirve para otros fines. Voy a explicarlo
aunque seguramente muchos piensen que es una barbaridad.

Vamos a pensar en el caso del almacén que comentabas tu antes.
Imaginemos que en este caso no uso código, sólo ID y Nombre. Decido
crear una ID cogiendo las 4 primeras letras del nombre. Enseguida
tendré problemas cuando además del almacén de Alcorcón, tenga el de
Alcoy. Supongamos que mi mecanismo de creación de IDs es más complejo y
tiene muy pocas posibilidades de que se vuelva a crear un registro con
la misma ID. Pero un buen día, yo decido cambiar el registro de
Alcorcón y llamarle Albacete, y meses después, vuelvo a insertar un
registro llamado Alcorcón. Si no cambié la PK (sí, sí, déjalo en que es
cabezonería), la ID generada volverá a ser idéntica a la que ya tenía y
chocarán. Bien, los números mágicos al fin y al cabo son dos dígitos
aleatorios que añado a esa secuencia alfanumérica, con lo cual en este
caso (suponiendo que la id fuera ALCO), puedo tener ALCO-27 y ALCO-67.
En otros casos he usado un autonumérico en otro campo y luego creado el
ID a partir de él, pero eso es justamente lo que tu estás criticando.

Sé que es retorcido, pero es sólo por mantener la virginidad de mis
PKs. Desde luego no difiere en exceso de usar un GUID o cualquier otro
mecanismo, con la salvedad de que es casero y no es 100% infalible.

En el caso de una factura y un artículo tiene sentido tener códigos,
pero en montones de otros casos no lo tiene. Meter sistemáticamente
códigos a todas las entidades es una tontería. Solo hay que codificar
cuando hace falta. Y en la gran mayoría de los casos los códigos deben
de ser alfanuméricos y nemotécnicos (o memotécnicos:). Por ejemplo el
código 'ALCO' es bastante mejor que el código 666 para referirse al
almacén de Alcorcón.

De acuerdo contigo, pero yo nunca he afirmado que siempre use códigos,
y la codificación siempre va a ser en este caso, propia del usuario que
guarda dichos registros (y no es capricho, el lo demanda).

Obviamente, en el caso que nos ocupa, siempre voy a necesitar hacer
joins para obtener a que nodo pertenece en un momento dado un personal

Se podría hacer con una simple selección y proyección.

Voy a tener que estudiarme el libro de Date hasta tener muy claro esto
último, pero por un momento habría jurado que es justo lo que yo
planteaba con un SELECT ... INNER JOIN ...

Lo vulnera por que representas la relación entre EB y 00 por medio de
una cadena de caracteres 'EB-00' en lugar de hacerlo utilizando una
tabla.

No existe tal relación. El 00 es un código de apoyo en la creación de
la clave, nada más.

Por supuesto que existe por que la podemos ver, y tu has explicado
como formas los identificadores asociando el código de nodo con otro
código. Obviamente los estás relacionando aunque luego permitas romper
la relación.

Por eso lo hago, porque luego puedo romper la relación.

Pero por que tienes un montón de redundancia.

Bajo mi punto de vista, una poca nada más y simplemente como
metodología de creación de claves con otros fines.

La redundancia en el modelo lógico es una chapuza siempre evitable.

Lo que estamos discutiendo es si se puede hacer mejor, y la respuesta
es: rotundamente si.

Ya. Aunque no era la cuestión inicial planteada, por supuesto que es
mejorable, sino no lo habría planteado.

Es más, si de repente decidiera hacer un recodificado
completo de todas las tablas (a nivel de la columna código que ve el
usuario), la PK ya no tendría ningún tipo de relación redundante con
el resto del registro, y respecto al código, imagina que es un
apéndice que sirve para muy poco, aunque se que esto último te
parecerá una estupidez (ya son muchos posts tuyos leídos, jejeje).

Yo creo que el problema es que tienes metido en la cabeza que las PK
no se pueden cambiar cuando es totalmente falso.

Sí, no quiero que se cambien las PKs, pero no opino por ello que no se
puedan cambiar. En otros diseños si las he hecho mutables.

Por cierto, me gustaría poder ver un día uno de tus diseños
medianamente complejos de una base de datos. Tengo mucha curiosidad por
ver como implementas en la práctica muchas de las ideas que planteas en
estos foros (y por supuesto, tomar ideas).

Saludos

http://www.moondance.tk