FK surrogada NULL o cero?

Hola Carlos,

Porque me imaginaba que me dirias algo similar? :)

Gracias por tu respuesta.

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


Saludos,

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

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

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

Pues nada .. al final me decido por los NULL, queda mas limpio en las
consultas.

Pero vamos .. está claro que hay que utilizarlo con mucha precaución


Saludos,

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

Hola Pablo,

On 14 sep, 18:04, "Pablo Roca" wrote:

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.

Dos tablas o las que sean. Depende de cuantas interpretaciones pueda
tener el hecho de que falta información.
O en vez de tablas, valores especiales como ha propuesto Alfredo.

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.

Todos los atributos deben tener siempre un valor en la 'escuela más
teórica'. Entonces automáticamente todos los atributos que forman
parte de una clave foránea tienen un valor.

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

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)

Pero como tu lo explicas yo veo ya las siguientes tablas:

Clientes
(
IdCliente (PK),
...
)

Delegaciones
(
IdCliente (FK Clientes),
IdDelegación (FK Clientes),
...
PK (IdCliente,IdDelegación)
)

Ordenes
(
IdOrden (PK),
ClienteOrdenante (FK Clientes),
...
)

OrdenesCosto
(
IdOrden (PK) (FK Ordenes),
CentroCoste,
...
)

OrdenesFactura
(
IdOrden (PK) (FK Ordenes),
ClienteFactura (FK Clientes),
...

Restricción:
ClienteFactura = Ordenes.ClienteOrdenante
OR
Exite (Ordenes.ClienteOrdenate, ClienteFactura) En Delegaciones
)

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

<...>

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)

<..>

He cortado gran parte de tu explicación porque saldría una respuesta
enorme.

No sé si entiendo bien este problema (seguro que no). Pero con lo
que entiendo... a ver que te parece esta idea:

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.

Pero.. insisto en que quizás no haya entendido el problema.

Saludos,
Carlos