FK surrogada NULL o cero?

Aclarar que estamos hablando de NULL's en claves foráneas.

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

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 llámalo "no aplica" o lo que quieras. No creo que haya necesidad de
discutir eso.

o simplemente no existe.

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

Bueno tal vez quise decir que el valor de dicho atributo no existe para una
determinada tupla.

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?

Con poco esfuerzo sé que interpretaras esa frase.

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

Totalmente de acuerdo, como creo reitero que reinventarla es suponer que en
sql server no sea apropiado asignar un NULL en el valor de una columna de
clave foránea de una relación opcional.

Hola Carlos,

El Sun, 14 Sep 2008 16:53:31 -0700 (PDT), Carlos M. Calvelo escribió:

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.

Supongo que si. Podría ser algo como:

create function CalendariosMal() returns bigint as
begin
return (select count(Calendario) from calendarioturnos t join
calendarioempleado e on t.calendario=e.calendario)
end

ALTER TABLE calendarioturnos CONSTRAINT [CK_CalendarioTurnos] CHECK
(CalendariosMal()=0)

ALTER TABLE calendarioEmpleado CONSTRAINT [CK_CalendarioEmpleado] CHECK
(CalendariosMal()=0)


Esto se llama una clave distribuida, y los lenguajes de bases de datos
deberían de tener soporte directo para poder expresarlas en una sola línea.
Aunque bueno, tu esto ya lo sabes de sobra O:-)


Saludos

Hola Pedro,

El Sun, 14 Sep 2008 20:13:52 -0400, Pedro escribió:

Bueno tal vez quise decir que el valor de dicho atributo no existe para una
determinada tupla.

Esto es una contradicción, por que una tupla es un conjunto de valores.

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?

Con poco esfuerzo sé que interpretaras esa frase.

Pero es un error. SQL Server comenzó siendo una imitación de System R y
copiaron también el gran error de los nulos. Mucha gente sabe que los nulos
son un error, pero no pueden eliminar sin reescribir SQL Server casi desde
0 ni sin tirar el estandar SQL a la basura. Que es justo lo que habría que
hacer si la informática fuese una industria seria.

Totalmente de acuerdo, como creo reitero que reinventarla es suponer que en
sql server no sea apropiado asignar un NULL en el valor de una columna de
clave foránea de una relación opcional.

Hombre, este es quizás el caso en el que los nulos sean menos dañinos. Pero
a lo que se refería Carlos es a que los nulos son una rueda cuadrada y es
mejor usar una redonda.


Saludos
Alfredo

Bueno tal vez quise decir que el valor de dicho atributo no existe para
una
determinada tupla.

Esto es una contradicción, por que una tupla es un conjunto de valores.

Pues mejor di "desconocido". Es difícil definir un concepto como el de
NULL.
Pero estoy seguro que entiendes lo que quise decir, igual que Carlos.
Insistir en ser tan preciso en una definición es desviar la discusión.
Mejor dénnos su definición de Null que yo la aceptaré humildemente :)

O si pueden, revisen:
http://en.wikipedia.org/wiki/Null_(SQL)

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?

Con poco esfuerzo sé que interpretaras esa frase.

Pero es un error. SQL Server comenzó siendo una imitación de System R y
copiaron también el gran error de los nulos. Mucha gente sabe que los
nulos
son un error, pero no pueden eliminar sin reescribir SQL Server casi desde
0 ni sin tirar el estandar SQL a la basura. Que es justo lo que habría que
hacer si la informática fuese una industria seria.

También Oracle, FireBird, SyBase, etc. tienen ese "gran error".
Pero comprando ese argumento, qué "valor"piensas que debe devolver una
columna al lado izquierdo de un Left Join cuando la condición no se cumple ?

O los Outer Join's son también un error? Verdad que no? Pues pienso que un
null para una columna de clave foránea tiene igual significado.

Totalmente de acuerdo, como creo reitero que reinventarla es suponer que
en
sql server no sea apropiado asignar un NULL en el valor de una columna de
clave foránea de una relación opcional.

Hombre, este es quizás el caso en el que los nulos sean menos dañinos.

Y es del caso que estamos hablando. Carlos trajo de los pelos la aritmética
con Nulls, lo cual no es el tema.

Pero
a lo que se refería Carlos es a que los nulos son una rueda cuadrada y es
mejor usar una redonda.

No creo que sea así.

O si pueden, revisen:
http://en.wikipedia.org/wiki/Null_(SQL)

http://en.wikipedia.org/wiki/Null_(SQL)