FK surrogada NULL o cero?

Hola Pablo,

El Sun, 14 Sep 2008 18:04:17 +0200, Pablo Roca escribió:

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).

Hombre, las vacaciones están para eso :-)

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)

Buf, a Celko tampoco hay que hacerle mucho caso :-)

que dicen
que una FK siempre debe tener un valor, porque una FK siempre apunta a una
PK y una PK siempre tiene valor ...

Y también estamos los que decimos que un atributo de una tupla siempre
tiene que tener un valor :-)

eso en teoría está bien, pero en la vida
real necesitamos que a veces no tenga valor una FK.

Pues yo no lo he necesitado nunca. :-?

Otra cosa es hacerlo como chapuza por que en SQL Server puede más rápido
que partir las tablas.

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.

Tampoco mucho más, es una consulta como otra cualquiera. Aunque es cierto
que manejar muchas tablas se vuelve incómodo.

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)

Yo utilizo identificadores alfanuméricos siempre que me dejan, y a veces
uso la cadena vacía para indicar que falta el dato.

Utilizar identificadores numéricos tiene poco sentido a no ser que tengas
que exprimir cada microsegundo, cosa que nunca es mi 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?

Pues aquí veo claramente que lo mejor es usar 3 tablas.

Calendario

Calendario VARCHAR(50) (PK)
Empresa VARCHAR(50)
Año SMALLINT
TotalHorasAño SMALLINT
JornadaMaxima TINYINT

CalendarioTurnos

Calendario VARCHAR(50) (FK a Calendario)
Turno VARCHAR(50) (FK a turnos)

CalendarioEmpleado

Calendario VARCHAR(50) (FK a Calendario)
Empleado VARCHAR(50) (FK a empleado)


Saludos

Hola Pedro,

On 15 sep, 00:06, "Pedro" wrote:

Claro que sí, para mi las consultas sobre todo de agregados quedan con una
mejor semántica cuando permites NULL,

TABLA
COL1 COL2
1 2
3 null
null 4

Prueba:

SELECT SUM(COL1+COL2), SUM(COL1)+SUM(COL2) FROM TABLA

Prueba ahora:

SELECT 1 + 3 + null
y
SELECT SUM(COL1) FROM TABLA

y después me hablas de 'semántica'.

Casos como estos... a patadas. Este ejemplo simple puede parecer
ridículo. Pero con una base de datos con cientos de tablas,
muchísimos datos y consultas que llenan varias pantallas...
vas a ver lo graciosos que son estos problemas.

no hay que hacer determinadas
excepciones en joins para excluir algunos registros foráneos que se
pusieron como completivos, etc.

Por qué querrías excluirlos? La intención es precisamente que estos
registros no desaparezcan de los joins. Que no formen un excepción.
Con los null, por arte de magia y la equivocación de alguno no se
volverían a ver jamás.

Saludos,
Carlos

Hola Pedro,

On 15 sep, 00:14, "Pedro" wrote:

Hay casos donde simplemente un valor es indefinido

Pues habrá que profundizar en la naturaleza de esa indefinición
y no pretender que lo indefinido se va a definir por si solo.

o simplemente no existe.

Y en todo caso no confundir indefinido con no existente.
Lo datos no existentes no hace falta registrarlos

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.

SQL Server sabe?

Por qué
reinventar la rueda ?

Lo de reinventar la rueda sí se dá mucho en nuestra profesión.
Especialmente lo de seguir reinventando ruedas cuadradas cuando
la redonda ya existe. :)

Saludos,
Carlos

Hola Alfredo,

On 15 sep, 00:34, Alfredo Novoa wrote:

CalendarioTurnos

Calendario VARCHAR(50) (FK a Calendario)
Turno VARCHAR(50) (FK a turnos)

CalendarioEmpleado

Calendario VARCHAR(50) (FK a Calendario)
Empleado VARCHAR(50) (FK a empleado)

En este caso necesitaría además la resticción de que
el mismo calendario no puede estar en estas dos tablas
a la vez. O en una o en la otra, pero no las dos.

(Si he interpretado bien el problema claro!)

Saludos,
Carlos

Yo me refería los null's en un campo de una clave foránea. Creo que era el
tema de que hablaba Pablo. Mencioné agregados pensando en el group by no en
el Sum y hablé de joins pensando en dichas relaciones.

Hacer aritmética con Null's pues... a quién se le ocurre?

Por qué querrías excluirlos? La intención es precisamente que estos
registros no desaparezcan de los joins.

Pues dependiendo del requerimiento de la consulta puede ser esa o no la
intención pero yo me atrevo a decir que la mayoria de las veces que uno usa
un (inner) join quiere ignorar las registros con valores indefinidos
(null's) para la relación en cuestión.
Y si quisieras mostrar también los indefinidos, pues usa LEFT join.

Con los null, por arte de magia y la equivocación de alguno no se
volverían a ver jamás.

La equivocación de alguno no creo que sea argumento.
Nos equivocamos hasta en los diseños.


"Carlos M. Calvelo" escribió en el mensaje
news:
Hola Pedro,