FK surrogada NULL o cero?

o ISNULL() en SQL SErver.



"Alhambra Eidos Kiquenet"
escribió en el mensaje
news:

Señor, puede poner un ejemplo de su uso de COALESCE en los outer join ??

Gracias.

Se me olvidaba decir que con SQL Server cuando hago un outer join SIEMPRE
relleno los "huecos" usando COALESCE.


Saludos

Es difícil entender lo que dices porque no se sabe cuando hablas en serio y
cuando estás ironizando o burlándote de lo que uno dice.

Alfredo, al menos, es mas directo y coherente.

Lo dejo aquí
Saludos.


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

On 15 sep, 02:13, "Pedro" wrote:

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.

Si "no aplica" no existe.

'Indefinido', 'no aplica', 'no existe', 'desconocido', 'desconocido
pero se sabe que existe', 'ya se actualizará esto algún día', 'solo
aplicable si es jueves', etc, etc, ...

Cual es el significado de los nulos?
Puede la falta de valores para mismo atributo tener significados
distintos para distintas tuplas?

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

Tal vez yo ya lo había interpretado así. :)
Si ese dato no existe, pues no existe. Y si un dato no existe no
hace falta registrar que no existe.

Esa tupla para la que ese dato no existe no es del mismo tipo que
las tuplas para las que sí existe. Por tanto no pueden pertenecer
todas a la misma relación (tabla).

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

Bueno... a ver que hago un esfuerzo :)

Los diseñadores de SQL Server (o cualquier otro SGBD SQL) solo
sabían lo que le dieron hecho los diseñadores de SQL (y las teorías
del gran Codd). Estos a su vez *quizás* pensaron, ante el problema
de que puede faltar información, que un diseño lógico correcto daría
lugar a muchas tablas. Confundiendo entonces el nivel lógico con el
físico decidieron que eso iba a representar un problema grave de
eficiencia (joins) porque pensaban que la correspondencia entre
relación a nivel lógico y los archivos (digamos tablas) a nivel
físico es de uno a uno. Y eso no tiene por qué ser así.
He ahí una interpretación; que no sé si es del todo correcta.

Con lo que sabemos hoy se podría decir que es un poco de ingenuos
el pensar que es lo mismo un diseño lógico y su conversión a un
diseño físico con muchas menos tablas aplicando el truco del nulo
y utilizar este último como diseño lógico.

Esa es mi interpretación de lo que 'sabe SQL Server': nada.
Le puedes decir que un atributo puede no tener valores y aceptar
nulos. Somos nosotros los que decidimos hacer eso o no y si lo
hacemos tendremos que darle una interpretación y saber cuales son
las consecuencias.

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

Apropiado, apropiado no sé. Como decisión de representar falta
de datos a nivel físico me parece mas o menos bien.
Como diseño lógico está mal. Una relación opcional se expresa con
como una relación (tabla) donde, si la relación entre dos tupas en
otras dos tablas (no necesariamente distintas) no existe con no
introducir esa tupla en esa relación.. ya está.

Saludos,
Carlos

El Mon, 15 Sep 2008 13:45:56 -0400, Pedro escribió:

En el fondo es lo mismo porque si se trata de un campo que sea una FK, con
cual valor los rellenas ?

Con el que me apetezca, normalmente con una cadena de longitud 0.


Saludos

El Mon, 15 Sep 2008 13:41:34 -0400, Pedro escribió:

Puede que sea más propenso a errores en algunos casos, que no creo sean de
más alto nivel, ni tal cosa sea la norma.

Es la norma y se ha escrito un montón sobre ese tema. A lo mejor el caso de
los identificadores que son FK es el menos propenso a errores, pero a mi
siguen sin gustarme nada, por que es fácil montarse un lío confundiendo las
cadenas de longitud 0 con nulos, y algunos SGBD tratan las cadenas vacías
de forma distinta a otros. Yo si veo un campo en blanco se que es una
cadena vacía y no me complico nada la vida.

Tendría que ver pruebas de eso
para aceptarlo.

Los libros y los artículos de Date tienen montones de pruebas.


Saludos

Ok, y qué ventaja tendría haber usado esa cadena en blanco en vez del
propio NULL ? No habría que convertirla en ambos casos a algo más legible
si se desea mostrar esos datos por ejemplo en un reporte ?



"Alfredo Novoa" escribió en el mensaje
news:1wmgjaglnge71$

El Mon, 15 Sep 2008 13:45:56 -0400, Pedro escribió:

En el fondo es lo mismo porque si se trata de un campo que sea una FK,
con
cual valor los rellenas ?

Con el que me apetezca, normalmente con una cadena de longitud 0.


Saludos