Es incorrecto el uso de null

"Alfredo Novoa" escribió en el mensaje
news:

Hola Leonardo,

Hola, Alfredo:

Ya la he apoyado con referencias a un libro.

Cualquiera hace eso...

AVG(edad)

y

SUM(edad)/COUNT(*)

Deberían devolver lo mismo pero si hay nulos no pasa.

El problema es el mismo en cualquiera de los tres casos posibles (-1, NULL o
una tabla partida)

Un agregado puede devolver un nulo aun cuando la columna no
permita nulos.
select sum(edad) from p where edad > 200.

¿Y eso se conecta con el tema en discusión de qué manera?

Otro ejemplo es si queremos obtener relación de las personas que
tienen la misma edad que ellos mismos.
select * from p where edad=edad

O lo que es lo mismo, SELECT * FROM Personas.

O, si te gusta escribir tonterias: SELECT * FROM Personas WHERE 1 = 1

Ademas de bien construida, he debido agregar "con sentido".

Cuando algo tan sencillo falla ya os podeis imaginar que
pasa con cosas más complicadas.

Irreal, el ejemplo.

Por ejemplo si queremos consultar las personas que no tengan la misma
edad que algún famoso.
select * from P where not exists(select * from Famosos F where
P.Edad=F.Edad)

Si hay un nulo en P entonces la tupla sale aunque en realidad si tenga
la misma edad que algún famoso. El SGBD miente.

La consulta está mal construída.
Podrias escribir:
SELECT * FROM P WHERE NOT (ISNULL(P) OR EXISTS (...))
Si tienes nulos debes tomar en cuenta su existencia.

Otra alternativa con IN que también falla:

select * from P where edad not in (select edad from Famosos)

Si en la tabla de famosos hay algún nulo la consulta nunca devuelve
nada aunque sea mentira.

select * from P where edad not in (select edad from Famosos WHERE NOT
isNull(Edad))

Problema resuelto.

Por consulta bien construída debe entenderse la consulta que toma en cuenta
las peculiaridades de los datos. Si crees que la obediencia de tus dogmas
excluye la posibilidad de escribir consultas incorrectas, vamos de culo.

Tenemos un SGBD que saca conclusiones incorrectas.

Si se le preguntan las cosas de manera incorrecta.

Si ordenas por un campo nulo cada SGBD hace lo que le da la gana.

Es normal. Si todos se comportaran igual, los fabricantes no tendrían
comportamientos idiosincráticos con los cuales amarrarte a su producto.

Los nulos se agrupan juntos usando GROUP BY.

Mejor eso que que se agrupen con otros valores, digo yo.

Null/0 debería devolver un error por operación indefinida, pero
devuelve un null.

NULL absorbe el resultado de cualquier operacion. Así está definido.

Tan proposición lógica es (a >= -1) como (a >= 0 OR ISNULL(a)).

Ninguna de las dos son proposiciones. Por favor infórmate un poco
antes de escribir. La segunda ni siquiera corresponde a un predicado.

La primera es una proposición, la segunda es un predicado.

Dos tablas y una relación son más complejas que una tabla.

Esto es una tontería.
Si fuese así, lo más sencillo sería que todas las bases de datos
tuviesen una sola tabla.

¿De verdad eres tan tonto, o es sólo una pose?

¿Pero quien te crees que eres?
Yo no tengo por que demostrarle nada al primer
descerebrado al que se le antoje.

Salud!

Hola, Carlos:

Tan proposición lógica es (a >= -1) como (a >= 0 OR ISNULL(a)).

Una proposición es una expresión de la que se puede decir que es
verdadera o falsa:
"2 + 2 son 4"
"Pepe tiene 20 años"
"7 - 5 son 345"

... (a >= -1) tambien es una proposición (que depende del valor actual de
a).

"La persona con id 6 se llama Juan, vive en Valencia y no se sabe
que edad tiene", (6,Juan,Valencia,null), no es una proposición
ejemplo del predicado escrito arriba porque hay que proporcionar un
valor para la variable EDAD. Esta proposición no es elemento del
producto cartesiano de los dominios. No es una proposición posible.

Concedido que formalmente puede ser una propuesta muy plausible.

Pero ocurre que hay veces en las que simplemente no se conoce un valor, pero
es necesario almacenar la información acerca de la persona. En esos casos
hay tres opciones: utilizar un valor artificial que no pueda ser una edad
válida, aceptar NULLs en la columna 'Edad' o usar una segunda tabla
relacionada con la primera como 1:(0,1). En este caso, la ausencia de un
valor correspondiente en la segunda tabla representaría la no disponibilidad
del valor. Y en este caso, cuando consideremos la totalidad de la
información disponible sobre la totalidad de las personas registradas, igual
obtendremos un NULL en la columna Edad.

O qué me dirías de esta:
'La persona de la que se desconoce el id, no se sabe como se llama,
ni donde vive, ni su edad'?
(null,null,null,null)

Es una burrada!

¿Pero tiene sentido plantearse el problema cuando se requiere, por ejemplo,
que toda tabla tenga una clave primaria?

Y si después de hacer eso le pregunto a la base de datos si conoce
a un tal José de Zaragoza de 34 años? Una posible respuesta es
'No' y otra muy distinta es 'No lo sé'.

No entiendo la diferencia. Si no sabe si lo conoce, no lo conoce.

EL 'SELECT AVG(EDAD) FROM PERSONAS' (ejemplo que tu has
puesto) ante la presencia de NULL's en la columna edad de la tabla
personas te está mintiendo.
La pregunta es 'Dame la media de edades de todas las personas'

Si entiendes que la tabla puede contener valores nulos en 'Edad', la
pregunta real es "dame la edad media de todas las personas cuya edad es
conocida". Por supuesto que no puedes obtener la edad media de todas las
personas aun cuando no conozcas su edad.

La respuesta correcta sería 'No lo sé'. Sin embargo el SGBD te dá
una media que simplemente no puede saber. Yo diría que la consulta
está bien construída y que el resultado es incorrecto.

Otra consulta sería: 'SELECT AVG(EDAD) FROM EDADES'. La pregunta es
entonces 'Dame la media de edades de aquellas personas para las que
se conoce su edad'. Y la repuesta es entonces correcta.

Es lo mismo.

Para las dos preguntas la respuesta puede ser la misma pero las
preguntas son distintas. El SGBD miente.

O no. El SGBD produce respuestas consistentes de acuerdo con reglas
conocidas. Si conoces las reglas sabes qué esperar. Y si no las conoces,
igual vas de culo.

Estos ejemplos son juegos de niños, pero el siguiente caso no.
Como consecuencia de los nulos una empresa para la que yo he
trabajado se estaba perdiendo poder reclamar 850000 dólares. El
fallo ha sido encontrado por casualidad sino hoy esa pérdida ya
iría por los 4 ó 5 millones de dólares.

¿Consecuencia de los nulos, o del desconocimiento de que los nulos existen
al momento de diseñar una o mas consultas?

¿No es factible que el pelma que diseñó mal las consultas pudiera haber
cometido otras tonterías equivalentes aun habiendo suprimido los nulos de
las tablas?

La gente cuando se le habla de lógica de proposiciones y lógica
de predicados no quiere entender pero cuando se le habla de
dólares son todo oídos.

Así funcionamos.

Salud!

Hola Leonardo,

Vistas ya las otras reacciones, solo un par de comentarios por
mi parte.

On 3 dec, 04:28, "Leonardo Azpurua" <l e o n a r d o [arroba] m v p s
[punto] o r g> wrote:

> O qué me dirías de esta:
> 'La persona de la que se desconoce el id, no se sabe como se llama,
> ni donde vive, ni su edad'?
> (null,null,null,null)

Es una burrada!

¿Pero tiene sentido plantearse el problema cuando se requiere, por ejemplo,
que toda tabla tenga una clave primaria?

Pues planteate este:

(1,null,null,null)
(2,null,null,null)
(3,null,null,null)
... etc ...

Piensa que los atributos nombre, ciudad y edad son totalmente
independientes unos de otros (solo dependen de la clave).

Tanto los null's como los duplicados y sus consecuencias ya han
hecho correr ríos de tinta; tanto en tablas base como en tablas
derivadas (resultados de consultas).
Mira por ejemplo 'gandy' en este mismo foro estos días tratando
de elimanar duplicados. Problema típico.

> Y si después de hacer eso le pregunto a la base de datos si conoce
> a un tal José de Zaragoza de 34 años? Una posible respuesta es
> 'No' y otra muy distinta es 'No lo sé'.

No entiendo la diferencia. Si no sabe si lo conoce, no lo conoce.

La diferencia es que si no hay nulos todas las proposiciones
que no están en la bbdd son consideradas falsas. Repito lo
del 'Closed World Assumption' (en castellano será algo como
'Suposición del Mundo Cerrado'.)
Si hay nulos se sabe que están representado una proposición
que es verdadera, pero no se sabe cual.

Una gran diferencia!


Saludos,
Carlos

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

Hola, Carlos:

Pues planteate este:

(1,null,null,null)
(2,null,null,null)
(3,null,null,null)
... etc ...

Las cosas no son tan en blanco y negros como las pintan.

En la práctica, las cosas funcionan más o menos así: alguien está diseñando
una base de datos, en una de cuyas tablas existe la posibilidad de que el
valor de una o más columnas sea desconocido.

Ante esa posibilidad hay tres soluciones: aceptar nulos en las columnas
correspondientes, definir un valor "artificial", ajeno al rango de variación
de la propiedad representada y usarlo como indicador de no disponibilidad o
partir la tabla.

Cada uno de estos métodos tiene sus ventajas e inconvenientes. Mi punto es
que cualquiera que sea la solución que adoptes tendras ventajas y
desventajas.

¿Que el NULL va a fallar cuando pidas que te de todas la personas donde Edad
= Edad? Bien, si se es tan idiota como para escribir en serio semejante
consulta, probablemente muchas cosas más fallen.

¿Que la función AVG te va a dar resultados falsos si optas por el NULL?
Depende de cómo lo interpretes. Y lo mismo, tampoco hay manera de obtener la
edad promedio de todas las personas si hay personas cuya edad desconoces.

Si existe la posibilidad de que solo conozcas, por ejemplo, el numero de
cedula, DNI o como lo llames de una persona, esa persona no puede estar en
la misma tabla donde están las otras, definitivamente. Si ese fuera el caso
(y me cuesta imaginar un escenario real -de "realidad"- en el que dicho caso
deba ser comtemplado) probablemente haría falta almacenar esas partículas en
una tabla separada.

Tanto los null's como los duplicados y sus consecuencias ya han
hecho correr ríos de tinta; tanto en tablas base como en tablas
derivadas (resultados de consultas).

Si hay nulos se sabe que están representado una proposición
que es verdadera, pero no se sabe cual.

Una gran diferencia!

Por más importante que sea la teoría para orientar la actividad práctica,
hay puntos en los cuales no queda más remedio que optar por algún tipo de
compromiso.

Si existe la posibilidad de que no conozcas el valor para un elemento de
información, y sin embargo existe la necesidad de almacenar los elementos
restantes, tienes que seleccionar una opción que tendrá sus pro y sus
contra.

Hagas lo que hagas, tienes un "hueco" en tu modelo de la realidad. Si
ignoras ese hueco, seguramente tendrás problemas.

En mi experiencia, que vale (para mi) mucho más que la opinión más experta,
es preferible permitir nulos en una columna que complicarme la vida
partiendo tablas. Por supuesto que todo tiene sus matices. Igual la ausencia
de un elemento de información puede llevarte a decidir que lo mejor es
guardar todas las tuplas incompletas en una tabla diferente (como con el
"DNI solitario" de arriba). Pero de ahí a estigmatizar cualquier uso del
NULL hay una gran diferencia.


Salud!

Hola Leonardo,

On 3 dec, 19:45, "Leonardo Azpurua" <l e o n a r d o [arroba] m v p s
[punto] o r g> wrote:

"Carlos M. Calvelo" escribió en el mensajenews:

Hola, Carlos:

> Pues planteate este:

> (1,null,null,null)
> (2,null,null,null)
> (3,null,null,null)
> ... etc ...

Las cosas no son tan en blanco y negros como las pintan.

Pero te dije que las columnas son totalmente independientes
unas de otras, solo dependen de la clave. Queriendo decir que
para cada null que ves no tiene nada que ver con el de al lado;
que lo que se puede hacer para una columna también se puede hacer
para las demás. Y lo que ves arriba es una consecuencia de eso.

En la práctica, las cosas funcionan más o menos así: alguien está diseñando
una base de datos, en una de cuyas tablas existe la posibilidad de que el
valor de una o más columnas sea desconocido.

Ante esa posibilidad hay tres soluciones: aceptar nulos en las columnas
correspondientes, definir un valor "artificial", ajeno al rango de variación
de la propiedad representada y usarlo como indicador de no disponibilidad o
partir la tabla.

Cada uno de estos métodos tiene sus ventajas e inconvenientes. Mi punto es
que cualquiera que sea la solución que adoptes tendras ventajas y
desventajas.

Los SGBDs que tenemos siempre nos confrontarán con los null's.
Puedes hacer elecciones a nivel físico. Por ejemplo si de una
columna se espera que tenga relativamente muchos null's; entonces
la ponemos en una tabla separada. Si se espera que solo unos
pocos registros tengan null para esa columna la dejamos en
esa tabla.

Pero esa es una decisión a nivel físico (espacio, tiempo).
A nivel lógico la clave y ese atributo tienen que ser otra
relación (tabla). Si no partimos la tabla tenemos que ser
conscientes de que tenemos en una tabla lo que tendrían que
haber sido varias. Ese es un problema que hay que gestionar;
tiene sus consecuencias para las consultas.

Alfredo dijo en su primer post en este hilo:

Lo malo es que si el SGBD es poco flexible con el modelo físico,
esto puede provocar una pérdida de rendimiento.

> Tanto los null's como los duplicados y sus consecuencias ya han
> hecho correr ríos de tinta; tanto en tablas base como en tablas
> derivadas (resultados de consultas).
> Si hay nulos se sabe que están representado una proposición
> que es verdadera, pero no se sabe cual.

> Una gran diferencia!

Por más importante que sea la teoría para orientar la actividad práctica,
hay puntos en los cuales no queda más remedio que optar por algún tipo de
compromiso.

Esos compromisos nos los imponen las caracteristicas de los
productos que usamos, no la lógica. Eso no es disculpa para
olvidarse de la lógica. A fin de cuentas el modelo físico
está ahi para implementar el diseño lógico. Tu pareces insistir
en querer olvidate de eso.

Lo dejo aquí, todo lo demás solo es mas de lo mismo.

Saludos,
Carlos