FK surrogada NULL o cero?

Hola Pablo,

On 14 sep, 17:38, "Pablo Roca" wrote:

Hola Carlos,

Porque me imaginaba que me dirias algo similar? :)

Es que no tenía muchas ganas de escribir y elaborar :-)

Gracias por tu respuesta.

Si, es una opción .. pero según que casos pues no la veo del todo.

Saludos,
Carlos

Claro que sí, para mi las consultas sobre todo de agregados quedan con una
mejor semántica cuando permites NULL, no hay que hacer determinadas
excepciones en joins para excluir algunos registros foráneos que se
pusieron como completivos, etc.



"Pablo Roca" escribió en el mensaje
news:%

Si, pues al final me decido por los NULL .. queda mucho mas limpio así en
las consultas


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Por cierto, Celko no está muy bien visto en la 'escuela más teórica'.
:)

Pero no en el tema de no usar claves artificiales, por lo menos.

Hay casos donde simplemente un valor es indefinido o simplemente no existe.
Creo que Null está precisamente para eso. SQL Server lo sabe desde hace
tiempo cuando da la opción de que un campo pueda ser NULL. Por qué
reinventar la rueda ?

"Pablo Roca" escribió en el mensaje
news:

Hola Alfredo,

Me alegro veros de vuelta a ti y a Carlos por el foro :) , hace tiempo que
no os leia (tambien estuve este verano un poco apartadillo).

Bien a lo que vamos .. hacer dos tablas? mm .. pues depende .. si y no.
Por un lado estan los de la escuela mas teórica (al estilo de Celko) que
dicen que una FK siempre debe tener un valor, porque una FK siempre apunta
a una PK y una PK siempre tiene valor ... eso en teoría está bien, pero en
la vida real necesitamos que a veces no tenga valor una FK.

Planteo por ejemplo dos situaciones:

1) ordenes de fabricación, en las cuales uno de los datos es el centro de
coste donde se cargan las horas, o incluso un campo donde indiques a que
cliente se está haciendo dicha orden de fabricación. Puede (y pasará) que
te topes que no sepas el centro de coste o ni tampoco a que cliente se
cargará (porque sea una corporación y no tengas claro que delegación de tu
cliente lo recogerá). Yo aqui separar las ordenes de fabricación no le veo
mucho sentido practico, porque las tendremos en tablas seperadas y despues
hacer un resumen sería mas complejo. En este caso sería mas partidario de
NULL o cero o un valor predefinido que indique Desconocido (para el caso
viene a ser muy parecido)

Otro caso, y es el que motivo mi pregunta aquí

2) Calendarios laborales.

Tengo que crear una tabla de calandarios laborales que va por Turno o por
Empleado. Los empleados pertenecen a un turno, pero en casos especiales
puede tener un calendario laboral propio. Detallo tablas

empleado

pk_empleado_id IDENTITY INT
nombre VARCHAR(50)

turnos

pk_turnos_id IDENTITY INT
descripcionturno VARCHAR(40)

La tabla de calendario la divido en dos

calendatos (contendrá las horas por cada fecha)

pk_calendatos_id IDENTITY INT
fk_pk_calendario_id INT (FK hacia calendario)
fecha DATETIME
horas INT

Calendario

pk_calendario_id IDENTITY INT
fk_pk_empresa_id INT
anio INT
totalhorasanio INT
jornadamaxima INT

y ahora viene el tema

fk_pk_turnos_id INT (FK a turnos)
fk_pk_empleado_id INT (FK a empleado)

Como dije antes un calendario laboral tiene la posibilidad de pertenecer a
un turno o a un empleado. Un empleado pertenece tambien a un turno. Con lo
que para buscar información de horas de un empleado habría que mirar en el
calendario si tiene la FK cubierta a empleado y si no pues irse al turno y
si no .. no tiene definidas horas

En este caso el registro de calendario tiene cubierto uno de las dos FKs
.. o hacia turnos o hacia empleados, nunca las dos. A mi poner NULLs en la
BBDD como que me dá un poco de pelusa .. y casi que era mas partidario de
poner un valor que no existe en la tabla relacionada (0 en este caso)

Si que se puede hacer en dos tablas, de esta manera:


Calenturnos

pk_calendario_id IDENTITY INT
fk_pk_empresa_id INT
anio INT
totalhorasanio INT
jornadamaxima INT
fk_pk_turnos_id INT (FK a turnos)

Calenemple

pk_calendario_id IDENTITY INT
fk_pk_empresa_id INT
anio INT
totalhorasanio INT
jornadamaxima INT
fk_pk_empleado_id INT (FK a empleado)

Si tenemos una consulta para ver que calendarios tenemos definidos habrá
que unir las dos tablas o hacer una vista.

¿Que opinais de estos casos?



Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Hola Pablo,

On 14 sep, 22:43, "Carlos M. Calvelo" wrote:

Un calendario pertenece siempre a un turno.
Empleados pertenecen a un turno (que es lo que dices al principio).
Un empleado entonces no necesita un calendario propio (para él solo),
sino un turno propio.

Voy a poner tu estructura original con los cambios que yo propongo
por si no me has entendido.

Empezando con tu estructura original:

empleado

pk_empleado_id IDENTITY INT
nombre VARCHAR(50)


turnos

pk_turnos_id IDENTITY INT
descripcionturno VARCHAR(40)


calendatos (contendrá las horas por cada fecha)

pk_calendatos_id IDENTITY INT
fk_pk_calendario_id INT (FK hacia calendario)
fecha DATETIME
horas INT


Calendario

pk_calendario_id IDENTITY INT
fk_pk_empresa_id INT
anio INT
totalhorasanio INT
jornadamaxima INT
fk_pk_turnos_id INT (FK a turnos) <<== Calendario es para un turno


Ahora, si todos los empleados tienen que pertenecer a algún turno
se añade un atributo a la tabla empleado:

empleado

pk_empleado_id IDENTITY INT
nombre VARCHAR(50)
fk_pk_turnos_id INT (FK a turnos)

Si lo anterior no es verdad, entoces en vez de eso añadímos otra
tabla donde se registra qué empleados pertenecen a qué turno.

EmpleadoTurno
pk_empleado_id INT (PK) (FK a empleados)
fk_pk_turnos_id INT (FK a turnos)


Saludos,
Carlos