FK surrogada NULL o cero?

Hola Pedro,

On 15 sep, 01:59, "Pedro" wrote:

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.

Bueno.. es que como vi lo de los agregados...

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

Pues bastante a menudo hay que hacerla. E interpretar el significado
de los nulos.

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

Tienes razón que puede ser esa o no la intención. Entonces teniendo
las tablas normalizadas se hace un join con una o con la otra
dependiendo de la intención. Esa intención es explícita entonces y
dará menos lugar a errores. Con los nulos eso no es tan obvio.

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

Todo el mundo sabe que ciertos mecanismos en lenguajes de
de programación dan mas lugar a errores que otros equivalentes
pero de mas alto nivel. Así como el confundir distintos niveles
de abstracción.

Yo he visto el caso donde el haber permitido un null en una FK
estaba dando lugar a una pérdida de $850.000,00. Equivocación
de alguno o no, con los nulos tenía que ver el asunto. Aunque
la lógica nos pueda fallar en otros aspectos, ese es un argumento
que pesa 850 Kg.

Por qué tengo la impresión de que no nos vamos a entender?

Saludos,
Carlos

El Mon, 15 Sep 2008 06:45:01 -0700, Alhambra Eidos Kiquenet escribió:

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

Pues por ejemplo:

select Nombre, DNI, Coalesce(Calendario, '') as Calendario from
Empleados e left outer join CalendarioEmpleado c on e.empleado=c.empleado


Saludos

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

Hola Pedro,

On 15 sep, 14:01, "Pedro" <pedrito> wrote:

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

Pues sí. Ahí ya empiezan los problemas.

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

Null es el objeto de estudio de la nulología: el conjunto vacío.
La nulología es entonces el estudio de 'absolutamente nada'. :-)

(O algo así, según Darwen)

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

Y no por eso es menor el 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 ?

Al lado izquierdo un left join devolverá todos los registros de esa
tabla. Seguro que quieres decir "al lado derecho".
Una posibilidad hubiera sido una columna donde los valores son
relaciones, pudiendo estas estar vacías. Pero eso no lo tenemos.
Pero si podemos determinar en el select que valores se devuelven
cuando ningún registro de la tabla a la derecha cumple la condición
del join. (Aunque sea un coñazo).

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.

Fué solo un ejemplo al haber mencionado tu los agregados.
Pero los problemas con los nulos no los tiene solo la aritmética.
Si quieres puedes tu mismo leer sobre lógica de tres valores,
closed world assumption y otras proezas sobre los nulos en el
enlace que has puesto a wikipedia.

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

Pues sí. A eso me refería.

Saludos,
Carlos

Hola Carlos,

El Mon, 15 Sep 2008 06:51:11 -0700 (PDT), Carlos M. Calvelo escribió:

Todo el mundo sabe que ciertos mecanismos en lenguajes de
de programación dan mas lugar a errores que otros equivalentes
pero de mas alto nivel. Así como el confundir distintos niveles
de abstracción.

Sin nulos hay 16 operadores lógicos y con nulos hay 19683, está bastante
claro en que caso es más fácil equivocarse.


Saludos
Alfredo