Es incorrecto el uso de null
Imac_man
mis preguntas son las siguientes:
1. ¿Es una mala practica permitir que los campos de mis tablas acepten
null?, si es asi ¿que es lo correcto cuando no quiero que se guarde algo en
los campos.?
2.¿El usar null en la mayoria de mis tablas hace que los tiempos de
respuesta en los querys se vean afectados?
gracias de antemano
Juan Diego Bueno
news:OUJd1V2M...@TK2MSFTNGP06.phx.gbl...
Parte de esto ya se trató hace tiempo, pero en un foro de C#. Del mensaje 26
en adelante, es donde se proporciona más información. Espero que te sirva
(a mi desde luego me enseñó mucho)
Saludos
Gux (MVP)
Como idea general, el valor nulo representa un valor desconocido. Por
ejemplo, una columna 'edad' de tipo INT puede almacenar cualquier tipo de
valor cuando se conoce la edad y usar NULL para representar que se desconoce
ese dato.
Desde el punto de vista teórico, en el modelo relacional cada valor toma un
valor de un dominio y NULL no es considerado un valor. Muchos diseñadores
prefieren usar valores artificiales de un dominio, por ejemplo -1 sería una
edad desconocida.
Como dije al comienzo, es un tema con muchas opiniones y
ventajas/desventajas. En general se considera a los valores nulos como una
mala idea. Hay mucho material para leer, le puedo sugerir un breve artículo:
NULL values in a database: A programmer's nightmare
http://www.databasedesign-resource.com/null-values-in-a-database.html
--
Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gux
--
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
Alfredo Novoa
Hola Gux,
On Fri, 30 Nov 2007 08:04:03 -0800, Gux (MVP)
<Gux...@discussions.microsoft.com> wrote:
>El tema de usar nulos en bases de datos es un debate de larga historia.
Pues si.
>Como idea general, el valor nulo representa un valor desconocido.
En realidad un nulo no es un valor, es una marca que indica que no hay
valor.
>Desde el punto de vista teórico, en el modelo relacional cada valor toma un
>valor de un dominio y NULL no es considerado un valor.
Correcto, aunque todos los valores son de un dominio.
> Muchos diseñadores
>prefieren usar valores artificiales de un dominio, por ejemplo -1 sería una
>edad desconocida.
Yo creo que esto no nos gusta a muchos. La solución que muchos
proponen es la partición vertical de las tablas.
Lo malo es que si el SGBD es poco flexible con el modelo físico, esto
puede provocar una pérdida de rendimiento.
>NULL values in a database: A programmer's nightmare
>http://www.databasedesign-resource.com/null-values-in-a-database.html
Gracias por el enlace.
Saludos
Alfredo
Alfredo Novoa
<alfr...@gmail.com> wrote:
>>Desde el punto de vista teórico, en el modelo relacional cada valor toma un
>>valor de un dominio
Bueno, esto sería que cada atributo de una tupla tiene un valor.
Saludos
Alfredo
Leonardo Azpurua
"Alfredo Novoa" <alfr...@gmail.com> escribió en el mensaje
news:4ke0l35bdvdpsflo2...@4ax.com...
Por otra parte, el dominio real de la categoría representada (mediante un
tipo de dato definido para el SGBD) puede incluir el valor NULL. Para el
caso de la Edad, por ejemplo, encuentro más correcto NULL (desconocida, no
disponible) que -1 (que sin duda está fuera del dominio de las edades,
aunque forme parte del dominio de los enteros).
Desde un punto de vista teórico, es igual de correcto o incorrecto usar NULL
que -1.
No tengo ningún problema con los NULL. De hecho, para el caso de datos como
las edades, el uso de valores artificiales (-1, por ejemplo) invalida los
resultados devueltos por cualquier función estadistica: SELECT AVG(Edad) se
vería alterado por los -1, pero no por los NULL.
Salud!
Alfredo Novoa
[punto] o r g> wrote:
> > Bueno, esto sería que cada atributo de una tupla tiene un valor.
>
> Por otra parte, el dominio real de la categoría representada (mediante un
> tipo de dato definido para el SGBD)
Un dominio real que yo sepa es un conjunto de numeros reales, y con lo
de categoría representada no se muy bien a que te refieres.
> puede incluir el valor NULL.
Eso si que no, un nulo no es un valor y nunca puede pertenecer a un
dominio, y menos a uno real.
> Para el
> caso de la Edad, por ejemplo, encuentro más correcto NULL (desconocida, no
> disponible) que -1 (que sin duda está fuera del dominio de las edades
> aunque forme parte del dominio de los enteros).
Pues por lo menos es un valor, cosa que un nulo no es. Pero mejor
partir las tablas.
> Desde un punto de vista teórico, es igual de correcto o incorrecto usar NULL
> que -1.
No, por que con un nulo rompes el Modelo Relacional y con un -1 no.
> No tengo ningún problema con los NULL. De hecho, para el caso de datos como
> las edades, el uso de valores artificiales (-1, por ejemplo) invalida los
> resultados devueltos por cualquier función estadistica: SELECT AVG(Edad) se
> vería alterado por los -1, pero no por los NULL.
Si, eso si. Pero partiendo las tablas funciona igual.
Saludos
Carlos M. Calvelo
On 2 dec, 00:33, Alfredo Novoa <alfred...@gmail.com> wrote:
> On 30 nov, 19:30, "Leonardo Azpurua" <l e o n a r d o [arroba] m v p s
> [punto] o r g> wrote:
>
> > > Bueno, esto sería que cada atributo de una tupla tiene un valor.
>
> > Por otra parte, el dominio real de la categoría representada (mediante un
> > tipo de dato definido para el SGBD)
>
> Un dominio real que yo sepa es un conjunto de numeros reales, y con lo
> de categoría representada no se muy bien a que te refieres.
No creo que se haya querido referir a los números reales.
Mas bien habrá querido decir 'real' como en 'de verdad'.
>
> > puede incluir el valor NULL.
>
> Eso si que no, un nulo no es un valor y nunca puede pertenecer a un
> dominio, y menos a uno real.
>
> > Para el
> > caso de la Edad, por ejemplo, encuentro más correcto NULL (desconocida, no
> > disponible) que -1 (que sin duda está fuera del dominio de las edades
> > aunque forme parte del dominio de los enteros).
>
> Pues por lo menos es un valor, cosa que un nulo no es. Pero mejor
> partir las tablas.
>
> > Desde un punto de vista teórico, es igual de correcto o incorrecto usar NULL
> > que -1.
>
> No, por que con un nulo rompes el Modelo Relacional y con un -1 no.
Yo entiendo que ese valor -1 no pertenece al dominio de las edades.
Entonces estoy de acuerdo con Leonardo en que si fuera posible
asignar valores no pertenecientes al dominio de un atributo es
tan correcto o incorrecto como asignar null.
Sería mas confuso todavía, porque para el null está claro que no
pertenece a ningún dominio y el -1 no pertenecería al dominio
de las edades pero si a otros (enteros por ejemplo).
Dicho de otra forma, el null nunca es un valor pero el -1
lo sería en unos casos y en otros no. De ahí que me parece
mas confuso.
>
> > No tengo ningún problema con los NULL. De hecho, para el caso de datos como
> > las edades, el uso de valores artificiales (-1, por ejemplo) invalida los
> > resultados devueltos por cualquier función estadistica: SELECT AVG(Edad) se
> > vería alterado por los -1, pero no por los NULL.
>
> Si, eso si. Pero partiendo las tablas funciona igual.
>
Mejor partir las tablas si.
Saludos,
Carlos
Leonardo Azpurua
-------------------------------------------------
Hola:
Un dominio real es un dominio que representa algo que existe en la realidad,
y la categoría representada es el universo que se representa mediante ese
dominio: edades, sueldos, nombres, distancias, etc. El Dominio de los
Numeros Reales es otra cosa que no tiene nada que ver con la discusión.
Cuando "partes las tablas", simplemente estás aumentando la complejidad del
modelo sin ningún beneficio en la visión conceptual del modelo. Las tuplas
creadas artificialmente no tienen sentido por si sólas; necesariamente debes
usarlas dentro de un JOIN, y cuando las uses dentro del JOIN pueden pasar
dos cosas: que desaparezca la tupla principal si no existe la dependiente, o
que te aparezca un NULL. El primer caso es malo. El segundo es lo mismo que
si tuvieramos el NULL dentro de la tabla.
Muy bonito lo de preservar el modelo relacional. No soy exactamente un
maestro en la teoría de las BD relacionales, pero tengo entendido que el
NULL forma parte de la definición, exactamente con el fin de permitir la
existencia de tuplas para las cuales algun valor no esté definido.
En la práctica, entonces, y salvo por la violación de un dogma (la unica
noticia de cuya existencia es tu afirmación), es exactamente igual partir
las tablas que aceptar NULL. Y como una tabla es siempre mejor que dos,
prefiero usar NULL en la tabla principal que partirla en dos para igual
tener que lidiar con los NULL en la vista.
Salud!
Alfredo Novoa
On 2 dic, 09:29, "Carlos M. Calvelo" <c_jac...@hotmail.com> wrote:
> Hola Alfredo,
> No creo que se haya querido referir a los números reales.
> Mas bien habrá querido decir 'real' como en 'de verdad'.
Pues que me expliquen que es un dominio de mentira :-)
> > > Desde un punto de vista teórico, es igual de correcto o incorrecto usar NULL
> > > que -1.
>
> > No, por que con un nulo rompes el Modelo Relacional y con un -1 no.
>
> Yo entiendo que ese valor -1 no pertenece al dominio de las edades.
> Entonces estoy de acuerdo con Leonardo en que si fuera posible
> asignar valores no pertenecientes al dominio de un atributo es
> tan correcto o incorrecto como asignar null.
Pero obviamente no es posible, asi que ni me lo planteo.
> Sería mas confuso todavía, porque para el null está claro que no
> pertenece a ningún dominio y el -1 no pertenecería al dominio
> de las edades pero si a otros (enteros por ejemplo).
> Dicho de otra forma, el null nunca es un valor pero el -1
> lo sería en unos casos y en otros no. De ahí que me parece
> mas confuso.
El -1 siempre es un valor, si quieres permitirlo en una columna de
edades es tu problema.
Si lo permites luego no puedes decir que es incorrecto. Con los nulos
igual, pero si los permites luego no puedes decir que tienes una base
de datos relacional.
Saludos
Alfredo
Alfredo Novoa
Hola Leonardo,
On 2 dic, 14:10, "Leonardo Azpurua" <l e o n a r d o [arroba] m v p s
[punto] o r g> wrote:
> Un dominio real es un dominio que representa algo que existe en la realidad,
Pues es la primera vez que veo tal cosa.
> y la categoría representada es el universo que se representa mediante ese
> dominio: edades, sueldos, nombres, distancias, etc.
Un dominio no representa ningún universo paralelo. Y ese uso de la
palabra categoría no viene en el diccionario ni en ningún otro sitio
que conozca.
El significado de la palabra categoría que más tiene que ver con este
contexto sería el de grupo de tipos, o incluso podría ser un sinónimo
de tipo por que un grupo de tipos no deja de ser otro tipo.
> El Dominio de los
> Numeros Reales es otra cosa que no tiene nada que ver con la discusión.
Ya, pero si te inventas el significado de las palabras es muy difícil
seguirte.
Pero vamos, que entiendo lo que quieres decir: que -1 no es una edad.
Pero eso al SGBD le da igual. Podrá ser una opción de diseño todo lo
poco elegante que tu quieras, pero desde el punto de vista de la
lógica simbólica es perfectamente correcta.
Un SGBD es un ingenio logico-deductivo que sigue las reglas que le
marcas. Si permites que pongan un -1 en la edad y alguien lo pone pues
todo correcto. Luego tiene que haber una persona o programa que
interprete las tuplas correctamente.
En cambio si permitimos nulos pues ya no tenemos un ingenio lógico-
deductivo que funciona correctamente, por que el tratamiento de los
nulos es lógicamente inconsistente. Una tupla con nulos deja de
corresponder a una proposición lógica y habrá consultas que devuelvan
resultados incoherentes.
> Cuando "partes las tablas", simplemente estás aumentando la complejidad del
> modelo sin ningún beneficio en la visión conceptual del modelo.
No es cierto, no se aumenta de ninguna manera la complejidad del
diseño por que se sigue representando la misma información.
Y yo creo que así el modelo representa más fielmente la realidad, por
que ni -1 ni null pueden ser edades.
> Las tuplas
> creadas artificialmente no tienen sentido por si sólas;
Ninguna tupla tiene sentido por si sola, tiene que haber algo o
alguien que las interprete.
> necesariamente debes
> usarlas dentro de un JOIN
Claro que no, todas las tuplas pueden interpretarse sin necesidad de
utilizar el operador de junta.
Por ejemplo (1, 30) puede significar que el cliente número 1 tiene 30
años. Esto evidentemente tiene sentido.
>, y cuando las uses dentro del JOIN pueden pasar
> dos cosas: que desaparezca la tupla principal si no existe la dependiente,
Lo cual representaría edad desconocida.
> o
> que te aparezca un NULL.
Esto nunca, quizás te estés confundiendo con el operador OUTER JOIN
que es completamente diferente a JOIN.
Para que un OUTER JOIN respete la lógica matemática (es decir: sea
relacional) no puede devolver nulos. O sea, que si no usas COALESCE te
estás cargando la lógica matemática.
> El primer caso es malo.
No tiene por que ser malo.
> El segundo es lo mismo que
> si tuvieramos el NULL dentro de la tabla.
Correcto, por que efectivamente tenemos nulos dentro de una tabla. El
resultado de una consulta que devuelve una tabla es una tabla :-)
> Muy bonito lo de preservar el modelo relacional.
Pues si, lo malo es que poca gente tiene presente que preservar el
Modelo Relacional es sinónimo de preservar la coherencia y la lógica
matemáticas. Creo que si la gente tuviese más presente esta
equivalencia, sabrían apreciar más adecuadamente el valor de preservar
eso del Modelo Relacional.
A lo mejor habría que usar menos la palabra "relacional" y más la
palabra "lógica".
> No soy exactamente un
> maestro en la teoría de las BD relacionales, pero tengo entendido que el
> NULL forma parte de la definición, exactamente con el fin de permitir la
> existencia de tuplas para las cuales algun valor no esté definido.
Todavía no hay unanimidad al respecto, pero la mayoría de los expertos
(sobre todo los buenos) consideran que los nulos fueron un error de
Codd y que no tienen cabida en el Modelo Relacional.
> En la práctica, entonces, y salvo por la violación de un dogma (la unica
> noticia de cuya existencia es tu afirmación)
Hombre, hay unas cosas que se llaman libros :-) Yo no me lo he
inventado.
Te puedo recomendar este para darle un repaso rápido a estos
conceptos:
http://www.amazon.co.uk/Database-Depth-Relational-Model-Practitioners/dp/0596100124
>Y como una tabla es siempre mejor que dos,
Huy, esto es un disparate.
Saludos
Alfredo
Leonardo Azpurua
> Hola Leonardo,
Hola, Alfredo:
> Pero vamos, que entiendo lo que quieres decir: que -1 no es una edad.
No todo está perdido :-)
> Pero eso al SGBD le da igual. Podrá ser una opción de diseño todo lo
> poco elegante que tu quieras, pero desde el punto de vista de la
> lógica simbólica es perfectamente correcta.
Como es perfectamente correcta la otra.
> Un SGBD es un ingenio logico-deductivo que sigue las reglas que le
> marcas. Si permites que pongan un -1 en la edad y alguien lo pone pues
> todo correcto. Luego tiene que haber una persona o programa que
> interprete las tuplas correctamente.
Lo mismo que con los NULL.
> En cambio si permitimos nulos pues ya no tenemos un ingenio lógico-
> deductivo que funciona correctamente, por que el tratamiento de los
> nulos es lógicamente inconsistente. Una tupla con nulos deja de
> corresponder a una proposición lógica y habrá consultas que devuelvan
> resultados incoherentes.
A menos que quieras que te considere como un pelma dogmático, deberías
apoyar esta afirmación con un ejemplo de una consulta *bien construída* que
devuelva resultados incoherentes como consecuencia de la existencia de un
NULL.
Tan proposición lógica es (a >= -1) como (a >= 0 OR ISNULL(a)).
Claro, la primera es más simple, pero en el paso siguiente vas a tener que
lidiar con el caso a = -1, y la simplicidad inicial desaparece.
>> Cuando "partes las tablas", simplemente estás aumentando la complejidad
>> del
>> modelo sin ningún beneficio en la visión conceptual del modelo.
>
>No es cierto, no se aumenta de ninguna manera la complejidad del
>diseño por que se sigue representando la misma información.
Dos tablas y una relación son más complejas que una tabla.
> Y yo creo que así el modelo representa más fielmente la realidad, por
> que ni -1 ni null pueden ser edades.
Lo mismo que "no me se la edad" tampoco puede ser una edad.
>> Las tuplas
>> creadas artificialmente no tienen sentido por si sólas;
>Ninguna tupla tiene sentido por si sola, tiene que haber algo o
>alguien que las interprete.
>
>> necesariamente debes
>> usarlas dentro de un JOIN
>
>Claro que no, todas las tuplas pueden interpretarse sin necesidad de
>utilizar el operador de junta.
>
>Por ejemplo (1, 30) puede significar que el cliente número 1 tiene 30
>años. Esto evidentemente tiene sentido.
>>, y cuando las uses dentro del JOIN pueden pasar
>> dos cosas: que desaparezca la tupla principal si no existe la
>> dependiente,
>Lo cual representaría edad desconocida.
Aquí me voy a dar de cabeza con otro de tus dogmas.
Tenemos:
PERSONAS (Id, Nombre)
EDADES (IdPersona, Edad)
con ua relacion de 1:(0,1).
Escribimos:
SELECT PERSONAS.*, EDADES.Edad
FROM PERSONAS, EDADES
WHERE PERSONAS.id = EDADES.IdPersona
y por supuesto, no obtenermos los datos de las personas cuya edad es
desconocida.
Tendríamos que escribir:
SELECT PERSONAS.*. EDADES.Edad
FROM PERSONAS LEFT OUTER JOIN EDADES
ON PERSONA.id = EDADES.idPersona
el resultado es una tabla, que incluye los datos completos de todas las
personas, incluyendo NULL en la edad de aquellas personas para quienes no
tenemos una edad. Es decir, lo mismo que si escribieramoas SELECT * FROM
PERSONAS si Edad fuera parte de PERSONAS y no de otra tabla, y si Edad
permitiera NULL, sólo que más complicado.
Hagas lo que hagas, cada vez que quieras acceder al conjunto de datos
*completos* de *todas las personas* vas a tener valores NULL en cualquiera
de las columnas para las cuales no dispongamos de información.
Da exactamente igual.
> Esto nunca, quizás te estés confundiendo con el operador OUTER JOIN
> que es completamente diferente a JOIN.
No. No me estoy confundiendo. Pero el tener que discernir el operador
correcto en vez de usar un simple SELECT filtrado ya es consecuencia de un
aumento en la complejidad.
> Para que un OUTER JOIN respete la lógica matemática (es decir: sea
> relacional) no puede devolver nulos. O sea, que si no usas COALESCE te
> estás cargando la lógica matemática.
Donde tienes COALESCE, que hay quienes tenemos que trabajar lo mismo con SQL
Server que con cualquier otra porquería muchísimo más limitada, y la teoría
o sirve para todo o no sirve para nada.
>> El primer caso es malo.
> No tiene por que ser malo.
No hombre, para nada. Que una consulta omita registros es un resultado
perfectamente aceptable.
>> El segundo es lo mismo que
>> si tuvieramos el NULL dentro de la tabla.
>> No soy exactamente un
>> maestro en la teoría de las BD relacionales, pero tengo entendido que el
>> NULL forma parte de la definición, exactamente con el fin de permitir la
>> existencia de tuplas para las cuales algun valor no esté definido.
> Todavía no hay unanimidad al respecto, pero la mayoría de los expertos
> (sobre todo los buenos) consideran que los nulos fueron un error de
> Codd y que no tienen cabida en el Modelo Relacional.
Tendría yo dieciseis años cuando leí "Heterodoxia" , de Ernesto Sábato.
Uno de los epigramas dice:
"Bach es mejor que Strauss, porque eso es lo que dicen los expertos"
y un poco más abajo dice:
"Un experto es un señor que dice que Bach es mejor que Strauss"
me dio risa, y me sigue dando risa, cada vez que alguien cita a "los
expertos".
Mi gran problema en la vida ha sido una absoluta incapacidad de respetar "la
autoridad", ni la de las autoridades (lo que me costó más de un mal rato e
incontables moretones) ni la de los expertos.
Y cuando llegamos al punto de citar autoridades, se me pasan las ganas de
seguir discutiendo.
Lo único importante es la práctica. Y los unicos criterios prácticos
importantes son la inteligibilidad del diseño y del contenido, la
simplicidad en la descripción de los procesos (declarativos o imperativos)
que usan los datos, y el rendimiento. Ir más allá es buscarle la quinta pata
al gato (un pasatiempo tan digno como
sacarse los mocos o pegarle fuego a los pedos).
Y basado en estos tres criterios, prefiero aceptar NULL en una columna que
colocar valores fuera del rango de variación de la categoría representada o
que crearme una segunda tabla.
Tienes la tarea de demostrarme que la presencia de un NULL en una columna
puede producir resultados incorrectos en una consulta bien construída. Todo
lo demás es paja.
Salud!
Alfredo Novoa
On 2 dic, 17:36, "Leonardo Azpurua" <l e o n a r d o [arroba] m v p s
[punto] o r g> wrote:
> > Pero vamos, que entiendo lo que quieres decir: que -1 no es una edad.
>
> No todo está perdido :-)
No, y tampoco era tan difícil decirlo sin hablar de universos
paralelos ni categorías de dominios hiperespaciales y condensadores de
fluzo :-)
> A menos que quieras que te considere como un pelma dogmático, deberías
> apoyar esta afirmación con un ejemplo de una consulta *bien construída* que
> devuelva resultados incoherentes como consecuencia de la existencia de un
> NULL.
Ya la he apoyado con referencias a un libro.
Aquí hay más libros:
http://www.dbdebunk.com/books.html
Pero por poner algunos ejemplos rápidos para abrir boca pues AVG() no
devuelve un resultado coherente por que si 1+null= null entonces
AVG(1,null) debería de ser null y no 1.
AVG(edad)
y
SUM(edad)/COUNT(*)
Deberían devolver lo mismo pero si hay nulos no pasa.
Las otras funciones de agregación además de AVG también dan problemas.
Un agregado puede devolver un nulo aun cuando la columna no permita
nulos.
select sum(edad) from p where edad > 200.
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
Obviamente todo el mundo tiene la misma edad que si mismo aunque no la
conozcamos, pero si hay nulos esas tuplas no aparecen.
Cuando algo tan sencillo falla ya os podeis imaginar que pasa con
cosas más complicadas.
Exists da muchos problemas y eso también lo explican los libros.
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.
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.
Tenemos un SGBD que saca conclusiones incorrectas.
Si ordenas por un campo nulo cada SGBD hace lo que le da la gana.
Los nulos se agrupan juntos usando GROUP BY.
Null/0 debería devolver un error por operación indefinida, pero
devuelve un null.
Hay un montón de equivalencias lógicas muy útiles que se pierden por
culpa de los nulos y hacen que las consultas se vuelvan más
complicadas. Por ejemplo x=x deja de ser cierto x=not x deja de ser
falso. x or not x deja de ser cierto, x and not x deja de ser falso,
etc. Un despropósito.
> 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.
> >No es cierto, no se aumenta de ninguna manera la complejidad del
> >diseño por que se sigue representando la misma información.
>
> 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.
> > Y yo creo que así el modelo representa más fielmente la realidad, por
> > que ni -1 ni null pueden ser edades.
>
> Lo mismo que "no me se la edad" tampoco puede ser una edad.
Claro, más a mi favor. Con nulos no tienes una columna de edades de
verdad por que puede haber por el medio cosas que no son una edad.
Mejor partir las tablas.
> Aquí me voy a dar de cabeza con otro de tus dogmas.
Ni son dogmas ni son míos. Es informática elemental y está en unas
cosas que se llaman libros.
> Tenemos:
> PERSONAS (Id, Nombre)
> EDADES (IdPersona, Edad)
>
> con ua relacion de 1:(0,1).
>
> Escribimos:
> SELECT PERSONAS.*, EDADES.Edad
> FROM PERSONAS, EDADES
> WHERE PERSONAS.id = EDADES.IdPersona
>
> y por supuesto, no obtenermos los datos de las personas cuya edad es
> desconocida.
>
> Tendríamos que escribir:
>
> SELECT PERSONAS.*. EDADES.Edad
> FROM PERSONAS LEFT OUTER JOIN EDADES
> ON PERSONA.id = EDADES.idPersona
¿Y por que habríamos de escribir esto?
> el resultado es una tabla, que incluye los datos completos de todas las
> personas, incluyendo NULL en la edad de aquellas personas para quienes no
> tenemos una edad. Es decir, lo mismo que si escribieramoas SELECT * FROM
> PERSONAS si Edad fuera parte de PERSONAS y no de otra tabla, y si Edad
> permitiera NULL, sólo que más complicado.
Exacto y por las mismas razones no hay que hacerlo.
Si quieres un resultado correcto puedes hacer algo como:
SELECT P.*, COALESCE(CAST(E.Edad as CHAR), 'Desconocida') as Edad
FROM PERSONAS P LEFT OUTER JOIN EDADES E ON P.id = E.id
> Hagas lo que hagas, cada vez que quieras acceder al conjunto de datos
> *completos* de *todas las personas* vas a tener valores NULL en cualquiera
> de las columnas para las cuales no dispongamos de información.
>
> Da exactamente igual.
No tienes ni idea.
> > Para que un OUTER JOIN respete la lógica matemática (es decir: sea
> > relacional) no puede devolver nulos. O sea, que si no usas COALESCE te
> > estás cargando la lógica matemática.
> Donde tienes COALESCE, que hay quienes tenemos que trabajar lo mismo con SQL
> Server que con cualquier otra porquería muchísimo más limitada, y la teoría
> o sirve para todo o no sirve para nada.
¡Que idiotez!
> > No tiene por que ser malo.
>
> No hombre, para nada. Que una consulta omita registros es un resultado
> perfectamente aceptable.
Pues claro si eso es lo que le pedimos.
> Mi gran problema en la vida ha sido una absoluta incapacidad de respetar "la
> autoridad", ni la de las autoridades (lo que me costó más de un mal rato e
> incontables moretones) ni la de los expertos.
Pero para poder hacer eso sin hacer el ridículo hay que estudiar y
razonar un poco.
La crítica basada en la ignorancia no es una cosa muy admirable.
> Y cuando llegamos al punto de citar autoridades, se me pasan las ganas de
> seguir discutiendo.
>
> Lo único importante es la práctica.
A mi las tonterías como estas también me quitan las ganas.
Como decía tu tocayo da Vinci: Los que se enamoran de la práctica sin
la teoría son como los pilotos sin timón ni brújula, que nunca podrán
saber a dónde van.
> Tienes la tarea de demostrarme que la presencia de un NULL en una
columna
> puede producir resultados incorrectos en una consulta bien construída.
¿Pero quien te crees que eres?
Yo no tengo por que demostrarle nada al primer descerebrado al que se
le antoje.
Carlos M. Calvelo
On 2 dec, 17:36, "Leonardo Azpurua" <l e o n a r d o [arroba] m v p s
[punto] o r g> wrote:
> "Alfredo Novoa" <alfred...@gmail.com> escribió en el mensajenews:0770c53f-6105-4219...@y5g2000hsf.googlegroups.com...
>
> > Hola Leonardo,
>
> Hola, Alfredo:
>
> > Pero vamos, que entiendo lo que quieres decir: que -1 no es una edad.
>
> No todo está perdido :-)
>
> > Pero eso al SGBD le da igual. Podrá ser una opción de diseño todo lo
> > poco elegante que tu quieras, pero desde el punto de vista de la
> > lógica simbólica es perfectamente correcta.
>
> Como es perfectamente correcta la otra.
>
> > Un SGBD es un ingenio logico-deductivo que sigue las reglas que le
> > marcas. Si permites que pongan un -1 en la edad y alguien lo pone pues
> > todo correcto. Luego tiene que haber una persona o programa que
> > interprete las tuplas correctamente.
>
> Lo mismo que con los NULL.
>
> > En cambio si permitimos nulos pues ya no tenemos un ingenio lógico-
> > deductivo que funciona correctamente, por que el tratamiento de los
> > nulos es lógicamente inconsistente. Una tupla con nulos deja de
> > corresponder a una proposición lógica y habrá consultas que devuelvan
> > resultados incoherentes.
>
> A menos que quieras que te considere como un pelma dogmático, deberías
> apoyar esta afirmación con un ejemplo de una consulta *bien construída* que
> devuelva resultados incoherentes como consecuencia de la existencia de un
> NULL.
>
> 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"
Las proposiciones lógicas a las que nos referimos hablando de bases
de datos relacionales son por ejemplo:
"La Persona con id 4 se llama Pedro, vive en Madrid y tiene una
edad de 30 años"
"La Persona con id 5 se llama Ana, vive en Sevilla y tiene una
edad de 35 años"
Que corresponden con los registros en una tabla:
(4,Pedro,Madrid,30)
(5,Ana,Sevilla,35)
El predicado del que estas proposiciones son ejemplos es:
"La persona con id ID se llama NOMBRE, vive en CIUDAD y tiene una
edad de EDAD años",
donde ID, NOMBRE, CIUDAD y EDAD son como variables a las que se le
puede atribuir valores para construir proposiciones. Estos valores
deben ser extraídos de sus correspondientes dominios.
Que es la cabezera de una tabla (nombres de atributos y sus
dominios/tipos): (ID int, NOMBRE char, CIUDAD char, EDAD Edad)
En una tabla se registran aquellas proposiciones para las que se
sabe que tienen un valor bolenano 'Verdadero'. Para todas las
proposiciones posibles (el producto cartesiano de los dominios de
todas las columnas) que no están en la tabla se considerea que
tienen un valor 'Falso'. (Closed world assumption).
"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.
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)
Y si la repetimos cien veces?
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é'.
La proposición anterior (donde solo no se sabía la edad) poco menos
ridícula es que estas últimas. Pero las consecuencias para la lógica
deductiva de la que se habla son las mismas.
Esa 'máquina logico-deductiva' a la que se refiere Alfredo trabaja
con estas proposiciones. La presencia de nulos rompe la capacidad
de deducción lógica hasta tal punto que el SGBD puede deducir
mentiras.
El LEFT JOIN es dos operadores a la vez: el JOIN con resultado
Personas.* y Edad y una UNION de ese resultado con
PERSONAS WHERE ID NOT IN (SELECT IDPERSONA FORM EDADES)
Esta última operación no está definida. Para una union relacional
las dos tablas tienen que tener el mismo número de atributos y del
mismo dominio.
Esta unión se la han inventado los diseñadores de SQL y hay que
saber cuales son sus problemas para poder evitarlos.
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'
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.
Para las dos preguntas la respuesta puede ser la misma pero las
preguntas son distintas. El SGBD miente.
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.
La genge 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.
Saludos,
Carlos
Carlos M. Calvelo
On 2 dec, 15:24, Alfredo Novoa <alfred...@gmail.com> wrote:
> On 2 dic, 09:29, "Carlos M. Calvelo" <c_jac...@hotmail.com> wrote:
>
> > No creo que se haya querido referir a los números reales.
> > Mas bien habrá querido decir 'real' como en 'de verdad'.
>
> Pues que me expliquen que es un dominio de mentira :-)
>
:)
Pues es un dominio de juguete. Para niños.
Tu también no entiendes nada! :)
Saludos,
Carlos
E.CORTIJO
Sres. le recomiendo que no pierdan su tiempo, hasta en los foros en ingles
este sr. es famoso!
----------------------------------------------------25 mayo 2003, 16:11
Grupos de noticias: borland.public.delphi.oodesign
Alfredo Novoa wrote:
| Sometimes I think I am just wasting my time conversating with people
| like you.
The please do us all a favour and don't waste any more of your time here.
| I am truly amazed about the lack of kwnolegde in this group.
Yes, I'm constantly amazed how little knowledge about OO one particular
RDBMS fanatic can bring to an OO (that means object-oriented) discussion
group.
| Nonsenses. It is evident you are not a good DBA.
Can a TeamB moderator please put an end to this continual insulting of my
good friends in this group?
Joanna
--
Joanna Carter
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
----------------------------------------------------
Grupos de noticias: borland.public.delphi.oodesign
De: Carl Caulkett <car...@dircon.co.uk>
On Sun, 25 May 2003 17:35:17 GMT, alfredo@nospam_ncs.es (Alfredo
Novoa) wrote:
>Sometimes I think I am just wasting my time conversating with people
>like you.
Goodbye. Watch out for the door/ass interface on your way out.
--
Carl
________________________________________
Grupos de noticias: comp.databases.theory
De: "Mikito Harakiri" <mikharak...@ywho.com>
Fecha: Tue, 18 Feb 2003 15:01:29 -0800
Local: Mart 18 feb 2003 19:01
Asunto: Re: Extending my question. Was: The relational model and relational
algebra - why did SQL become the industry standard?
"Alfredo Novoa" <alfr...@ncs.es> wrote in message
> > Why? View updates is about ability to solve equations with relational
> > operators. While one can certainly claim that Set Algebra is superior
to
> > Bag Algebra, you have to demonstrate what exact technical difficulties
are
> > solving equations in the Bag Algebra.
> The systematic approaches to the view update problem based on
> predicate logic does not work with bags.
I have a doubt about Date's approach. Is he treating each operation
individually; independently of each other? Is he treating each new tuple
inserted into a relation individually; unrelated to other tuples inserted
(in the same transaction)?
Returning to the example
select id, 'VOICE' type, voice phone
from contact
union
select id, 'FAX' type, fax phone
from contact
we can easily see that both assumtions aren't correct:
1. Sucessively applied operations can't be considered independently of each
other. In the above example union can't be considered independently of the
antiprojection (BTW, what is the correct term for adding a pseudocloumn?).
2. Two tuples inserted together into a derived relation correspond to a
single tuple insertion in the base relation. The approach based upon "single
tuple" translation is flawed.
Leonardo Azpurua
> 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!
Leonardo Azpurua
>> 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!
Alfredo Novoa
Hola Carlos,
On Sun, 2 Dec 2007 17:20:02 -0800 (PST), "Carlos M. Calvelo"
<c_ja...@hotmail.com> wrote:
>El predicado del que estas proposiciones son ejemplos es:
>"La persona con id ID se llama NOMBRE, vive en CIUDAD y tiene una
> edad de EDAD años",
>donde ID, NOMBRE, CIUDAD y EDAD son como variables a las que se le
>puede atribuir valores para construir proposiciones. Estos valores
>deben ser extraídos de sus correspondientes dominios.
Es decir que la diferencia está en que hemos introducido variables.
Es decir los predicados son funciones lógicas o también llamadas
booleanas.
Por supuesto toda proposición también es un predicado. Caso degenerado
le llaman :-)
>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.
>
>La genge 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.
Pues si, y apuesto algo a que el programador que causó la pérdida de
los 850000$ tampoco quería saber nada de lógica y matemáticas.
Saludos
Alfredo
Alfredo Novoa
[arroba] m v p s [punto] o r g> wrote:
>... (a >= -1) tambien es una proposición (que depende del valor actual de
>a).
Por favor, lee con más cuidado, se te ha dicho unas cuantas veces que
si hay variables no es una proposición, es un predicado.
>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.
En realidad hay muchas más opciones como por ejemplo crear una tabla
para representar los casos desconocidos. El caso es utilizar una
opción que esté dentro de las reglas de la lógica matemática.
> 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.
Ya se te ha explicado varias veces que esto es falso.
>> 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?
El problema es que SQL no requiere que toda tabla tenga alguna clave.
>> 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.
Eso para ti, pero una máquina no es capaz de deducir eso. Si no sabe
si lo conoce entonces no sabe si lo conoce. Igual que no es capaz de
deducir que una persona tiene la misma edad que si misma cuando no
conoce la edad.
>> 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".
Entonces ya no calcula la media, es una operación distinta que se
llama igual y esto es una de las muchas inconsistencias.
> Por supuesto que no puedes obtener la edad media de todas las
>personas aun cuando no conozcas su edad.
Por supuesto. El SGBD te devuelve un resultado que no es la media de
todas las personas.
>> 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.
No lo es por que aquí calcula la media de todas las tuplas y AVG(EDAD)
es igual a SUM(EDAD)/COUNT(*). Es decir que aquí es una media de
verdad y no una cosa rara inventada por los diseñadores de SQL.
>> 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.
Reglas conocidas que son inconsistentes que hacen que el SGBD produzca
respuestas que son mentira, como que una persona no tiene la misma
edad que si mismo.
Hay montones de comportamientos anti intuitivos.
select * from P where edad = 30 or edad <> 30;
Esto debería de devolver todas las tuplas por que si sumamos las
personas que tienen 30 años y las personas que no tienen 30 años
deberíamos tener a todas las personas aunque no conozcamos sus edades.
Pues con nulos tampoco funciona.
>¿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?
Si, es factible pero mucho menos probable.
Por ejemplo la lógica de dos valores tiene solamente 16 operadores
posibles, pero si incluimos los nulos entonces los 16 se transforman
en 19683 con lo que la complejidad se multiplica por más de 1000 y con
ello las probabilidades de errores humanos se disparan. Yo estoy harto
de corregir esos errores.
Si el pelma que diseño la base de datos no hubiese permitido los nulos
y el pelma que diseñó las consultas dominase la lógica matemática, las
probabilidades de error habrían sido una pequeñísima fracción de las
que fueron.
En realidad la inmensa mayor parte de la culpa la tuvo el que dejo
meter los nulos.
>> 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.
Y así nos va.
Saludos
Alfredo Novoa
<alfr...@gmail.com> wrote:
>Pues si, y apuesto algo a que el programador que causó la pérdida de
>los 850000$ tampoco quería saber nada de lógica y matemáticas.
Bueno, el programador o el DBA o los dos :-)
Saludos
Alfredo
Alfredo Novoa
<alfr...@gmail.com> wrote:
>Por ejemplo la lógica de dos valores tiene solamente 16 operadores
>posibles, pero si incluimos los nulos entonces los 16 se transforman
>en 19683 con lo que la complejidad se multiplica por más de 1000 y con
>ello las probabilidades de errores humanos se disparan. Yo estoy harto
>de corregir esos errores.
Para los curiosos 16 sale de 2^2^2 y 19683 sale de 3^3^3
Saludos
Alfredo Novoa
Hola Leonardo,
On Sun, 2 Dec 2007 23:11:44 -0400, "Leonardo Azpurua" <l e o n a r d o
[arroba] m v p s [punto] o r g> wrote:
>> Ya la he apoyado con referencias a un libro.
>
>Cualquiera hace eso...
Pues a ver si empiezas a hacerlo tú también para sostener tus
afirmaciones.
Aunque dudo que algún autor o editor se atreva a publicar un libro que
diga que el tratamiento de los nulos que hace SQL es consistente. Se
convertirían en el hazmereir.
>> 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)
Por supuesto que no. En la tabla partida y con el -1 no hay nulos y
entonces AVG(EDAD) es igual a SUM(EDAD)/COUNT(*)
Si no te fijas un poco más será muy difícil discutir contigo.
>> 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?
Pues en que el tratamiento de los nulos de SQL es inconsistente y ni
siquiera prohibiendo los nulos en las tablas te libras de todos los
problemas.
>> 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
>
>Ademas de bien construida, he debido agregar "con sentido".
Ya, y luego añadirás más tonterías. El caso es llevar la contraria y
negar lo que todo el mundo que entiende un poco del tema sabe de
sobra.
>> Cuando algo tan sencillo falla ya os podeis imaginar que
>> pasa con cosas más complicadas.
>
>Irreal, el ejemplo.
¿Pero ves la inconsistencia o no?
¿Desde cuando se exige que los ejemplos seran reales? ¡Vamos hombre!
>> 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.
La que está mal construida es la tuya. La mía puede devolver
resultados falsos si hay nulos, que es lo que se supone que tenía que
demostrar.
>> 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.
No, no está resuelto, mi consulta sigue devolviendo resultados falsos
cuando hay nulos.
Pero menudo Einstein estás hecho, me filtras los nulos de mis
consultas y luego me dices que así ya funcionan X-DD
aunque será: WHERE Edad is not null
Pues claro que si hombre, de eso se trata, de eliminar los nulos, algo
aprendes, pero es mucho mejor que ya no permitamos introducirlos en
las tablas que andar eliminándolos después :-)
Así ya no tenemos que estar siempre parcheando las consultas para
evitar las inconsistencias de SQL. Por que el día que nos olvidemos o
nos equivoquemos al hacerlo la podemos liar pero bien.
>> 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.
Pues a mi desde luego que no me pillan por ahí :-)
>> Los nulos se agrupan juntos usando GROUP BY.
>
>Mejor eso que que se agrupen con otros valores, digo yo.
Pero peor que que no se agrupen. Están agrupando cosas que no saben
sin son iguales. Es una evidente inconsistencia.
>> 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.
Mentira, por ejemplo el OR no lo absorbe.
select * from P where a=1 or b=1
Si b es nulo y a es 1 entonces te devuelve la tupla. No hay absorción.
>>> 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.
¡Que paciencia hay que tener!
Si hay variables no es una proposición. Lo otro para que explicarlo
otra vez si ya se que no lo vas a entender.
Hala, ya me cansé.
Carlos M. Calvelo
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
On 3 dec, 16:07, Alfredo Novoa <alfred...@gmail.com> wrote:
> On Sun, 2 Dec 2007 23:11:44 -0400, "Leonardo Azpurua" <l e o n a r d o
>
> >> 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)
>
> Por supuesto que no. En la tabla partida y con el -1 no hay nulos y
> entonces AVG(EDAD) es igual a SUM(EDAD)/COUNT(*)
>
Bueno... con el -1, no creo.
Saludos,
Carlos
Carlos M. Calvelo
creo que sí serán iguales, pero no que sea correcto.
Saludos,
Carlos
Alfredo Novoa
Hola Carlos,
On Mon, 3 Dec 2007 08:59:54 -0800 (PST), "Carlos M. Calvelo"
<c_ja...@hotmail.com> wrote:
>creo que sí serán iguales, pero no que sea correcto.
Si, el -1 falsea la media, pero el SGBD hace bien la media de lo que
le das.
Con nulos el SGBD no hace una media, hace otra cosa.
Saludos
Leonardo Azpurua
"Carlos M. Calvelo" <c_ja...@hotmail.com> escribió en el mensaje
news:b46467e8-557e-4d5a...@o6g2000hsd.googlegroups.com...
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!
Carlos M. Calvelo
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" <c_jac...@hotmail.com> escribió en el mensajenews:b46467e8-557e-4d5a...@o6g2000hsd.googlegroups.com...
>
> 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
Alfredo Novoa
[punto] o r g> wrote:
> Las cosas no son tan en blanco y negros como las pintan.
Las cosas están muy claras para el que se ha tomado la molestia de
estudiar esto un poco, pero siempre hay alguien intentando
emborronarlas.
> 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.
Como ya he dicho hay más soluciones. El propio desconocimiento de algo
también es información y esa información se puede representar en
tablas. Es decir podemos crear una tabla para escribir en ella que no
conocemos algo. Además esto nos sirve para representar más cosas como
por ejemplo: valor no aplicable.
> Cada uno de estos métodos tiene sus ventajas e inconvenientes.
Y de eso estamos hablando. Y resulta que hay métodos con más ventajas
y menos desventajas que otros.
> Mi punto es
> que cualquiera que sea la solución que adoptes tendras ventajas y
> desventajas.
Eso es como no decir nada. Habrá que ver cuales son esas ventajas y
desventajas y escoger la mejor opción.
Y ya hemos visto unas cuantas de las desventajas de los nulos como por
ejemplo el enorme incremento del riesgo de errores al aumentar
exponencialmente la complejidad de las operaciones lógicas.
Aumentar el riesgo de errores implica casi siempre perder dinero.
> 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.
¿Y como sabemos que este es uno de esos puntos?
Habría que demostrar eso primero antes de saltarnos la teoría.
Y por supuesto aquí no se a aportado ningún argumento en favor de este
caso.
Si no queda más remedio que saltarnos la teoría pues nos la saltamos,
pero saltarnosla por capricho o ignorancia es irresponsable, sobre
todo cuando es tan peligroso.
> Hagas lo que hagas, tienes un "hueco" en tu modelo de la realidad. Si
> ignoras ese hueco, seguramente tendrás problemas.
Pues hasta ahora no se ha visto que la solución de partir las tablas
tenga algún problema
> 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.
Es que no es ninguna complicación, es lo más normal del mundo, igual
que normalizar.
Saludos
Leonardo Azpurua
"Alfredo Novoa" <alfr...@gmail.com> escribió en el mensaje
news:0436acee-1876-4d0e...@w34g2000hsg.googlegroups.com...
>> Las cosas no son tan en blanco y negros como las pintan.
>
> Las cosas están muy claras para el que se ha tomado la molestia de
> estudiar esto un poco, pero siempre hay alguien intentando
> emborronarlas.
Tampoco es cosa de ponerte frenética.
¿Has estudiado mucho sobre BBDD? Pues bien, felicitaciones. Yo he estudiado
mucho sobre unas cosas, menos sobre otras y sobre muchas nada.
Me has explicado varias veces toda tu teoría sobre los nulos, y ya entendí.
Simplemente me parece que llevarla a los casos límite que tanto te preocupan
es una idiotez. ¿Quién en su sano juicio va a escribir SELECT * FROM x WHERE
Edad = Edad? ¿A quien le importa la diferencia entre no lo conozco o no sé
si lo conozco? ¿Puedes o no puedes darme la información que te pido? Eso es
lo único que me importa: lo demás son pendejadas y afán de corregir al
prójimo.
No hay que ser Einstein para darse cuenta de que si tomas en cuenta la
posibilidad de que existan nulos en una columna, los nulos no te darán
problemas. Para lo que hace falta una inteligencia media (que no te la da el
estudio, desafortunadamente) es para entender lo que dice el otro, y en eso
vas de culo a una velocidad vertiginosa.
Por más teoría que le pongas al diseño de tus bases de datos, no vas a
lograr que un chimpancé las use correctamente. Hasta ahora no he tenido
ningún problema a causa de los NULL (que, por otra parte evito siempre que
puedo). Si alguna vez los tengo paso por aquí y te cuento.
De todas maneras, ahórrate la bilis, que no pienso diseñar un SGBD.
Salud!
Alfredo Novoa
[punto] o r g> wrote:
> ¿Has estudiado mucho sobre BBDD? Pues bien, felicitaciones. Yo he estudiado
> mucho sobre unas cosas, menos sobre otras y sobre muchas nada.
El problema es que te pones a opinar sobre una de las cosas que no has
estudido nada y haces el ridículo de forma lamentable.
> Me has explicado varias veces toda tu teoría sobre los nulos, y ya entendí.
Por lo que veo aun no te has enterado de nada y la paciencia de uno no
es infinita. Ya me gustaría que esa teoría fuese mía...
Leonardo Azpurua
>> ¿Has estudiado mucho sobre BBDD? Pues bien, felicitaciones. Yo he
>> estudiado
>> mucho sobre unas cosas, menos sobre otras y sobre muchas nada.
>
> El problema es que te pones a opinar sobre una de las cosas que no has
> estudido nada y haces el ridículo de forma lamentable.
Creo que el ridículo lo haces tu con ese dogmatismo autoritario.
Borges se reía de los escritorzuelos capaces de emborronar dieciocho páginas
para impedir la repetición de un simple "que". Otros nos reímos de los
teóricos capaces de partir una tabla en dos para impedir un simple NULL.
Tu autoridad son los libros, los ejemplos absurdos y los insultos. Salvo un
desprecio insultante por los argumentos no has sido capaz de demostrar
absolutamente nada.
> Por lo que veo aun no te has enterado de nada y la paciencia de uno no
> es infinita. Ya me gustaría que esa teoría fuese mía...
A mi también, porque si tuvieras cualquier cosa que fuese tuya tal vez
serías un poco menos intolerante.
Salud!
Alfredo Novoa
[punto] o r g> wrote:
>
> > estudido nada y haces el ridículo de forma lamentable.
>
> Creo que el ridículo lo haces tu con ese dogmatismo autoritario.
Sigues sin entender absolutamente nada, no es dogmatismo, es ciencia.
Algo que no sabes lo que es por que eres un anti intelectual de la
peor especie, y te esfuerzas para acumular ignorancia.
> Borges se reía de los escritorzuelos capaces de emborronar dieciocho páginas
> para impedir la repetición de un simple "que". Otros nos reímos de los
> teóricos capaces de partir una tabla en dos para impedir un simple NULL.
Y por supuesto también te reirás de los que parten una tabla para
normalizar una base de datos. Por que eso de la normalización también
será dogmatismo autoritario para ti.
A saber de cuantos más hechos cientítificos demostrados también te
ríes como un paleto.
> Tu autoridad son los libros, los ejemplos absurdos y los insultos. Salvo un
> desprecio insultante por los argumentos no has sido capaz de demostrar
> absolutamente nada.
He demostrado lo que me has pedido sobradamente y lo sabes. SQL es
inconsistente y los miembros del comité SQL lo admiten abiertamente
(algunos de los ejemplos eran de uno de ellos). Ahora resulta que tú
sabes más que ellos y más que todos y el mundo es injusto por que no
reconoce tu genialidad.
Los errores debidos a la complejidad y a la falta de intuitividad de
la lógica de más de dos valores son algo de lo más habitual, y los
profesionales de verdad lo saben de sobra incluso mejor que los
teóricos. El ejemplo de los 840000$ de Carlos no es nada fuera de lo
común.
Además de bocazas ignorante, careces de la más mínima honestidad
intelectual (término que seguro que desconoces) y eres incapaz de
admitir que te has equivocado.
Ignoras sistemáticamente los mejores argumentos del contrario y te
dedicas a intentar emborronar las cosas. Pides algo pensando en que no
van a poder dártelo y cuando te lo dan reaccionas cambiando las reglas
y negando que te han dado lo que has pedido.
Menudo elemento.
Leonardo Azpurua
> He demostrado lo que me has pedido sobradamente y lo sabes. SQL es
> inconsistente y los miembros del comité SQL lo admiten abiertamente
> (algunos de los ejemplos eran de uno de ellos). Ahora resulta que tú
> sabes más que ellos y más que todos y el mundo es injusto por que no
> reconoce tu genialidad.
Nadie ha dicho nada acerca de la consistencia o inconsistencia de SQL.
Fuiste tu quien armó una alharaca porque dije que prefería permitir nulos en
una columna que partir la tabla. Eres tu quien por el único gusto de
incordiar te vas por los cerros de Úbeda cada vez que se te lleva la
contraria en el más insignificante detalle.
Los ejemplos que me has dado o son totalmente absurdos (SELECT * FROM x
WHERE Edad = Edad) o son dogmáticos (AVG(x) debe ser igual a
SUM(x)/COUNT(*): sí, debería, pero resulta que x puede contener nulos,
entonces AVG(x) no debe ser igual a nada).
Lo de los 850.000$ no fue un ejemplo: fue una anécdota. Ni siquiera se
describe de qué manera se produjo la pérdida y por qué la culpa fue de los
nulos (y no de quien obtuvo los datos ignorando que los nulos podían
existir) ni como un cambio en el diseño de la BBDD podría haber impedido esa
situación.
Lo único que digo es que me parece más simple permitir un nulo en una
columna que partir la tabla con el unico fin de impedir los nulos. Y tu
única respuesta es ponerte a insultar como una loca en nombre de la ciencia,
en vez de proporcionar una sóla demostración práctica de por que es mejor lo
contrario.
La "honestidad intelectual", además de la humildad necesaria para reconocer
que uno se equivoca, es el valor de mantener las opiniones mientras se cree
en ellas, aunque nunca falte un pelmazo que te tire libros a la cabeza.
Entiendo las objeciones teóricas al uso de nulos. Pero me sigue pareciendo
que en la práctica son la mejor manera de representar la no disponibilidad
de un elemento de información.
Además de (y más que) la realización de un conjunto de principios de diseño,
las BBDD modelan elementos y relaciones del mundo real, y las modelan según
nuestro conocimiento de esos elementos y relaciones: si nuestro conocimiento
es imperfecto o incompleto, debemos dejar un margen para esa imperfección y
esa incompletitud. Los problemas derivados de permitir nulos en ciertas
columnas van a ocurrir de cualquier manera, a menos que quien lidia con los
datos reconozca que pueden estar incompletos. Y eso va a pasar
independientemente de como los organices.
Si en vez de insultarme o apabullarme con dogmas intentaras darme un
ejemplo que demuestre (pero que realmente demuestre) que es mejor partir las
tablas que permitir nulos, estaría dispuesto a reconocer mi error.
De momento, si escribo SELECT * FROM X y me encuentro que en la columna C de
una tupla hay un NULL, entiendo de inmediato que el valor de C no está
disponible para esa tupla. Tu dogma requiere que vea si en Z existe un
registro donde Z.PK = X.PK para saber si el valor de C está o no está
disponible, o que reemplace el select anterior por SELECT X.*, Z.C FROM X
LEFT JOIN Z ON X.Clave = Z.Clave, para obtener lo mismo (incluyendo el NULL)
que habría obtenido con el primer select.
Sigue llamándome cosas y recomendándome libros, porque sigo sin ver las
ventajas de tu propuesta.
Salud!
Alfredo Novoa
[arroba] m v p s [punto] o r g> wrote:
>Nadie ha dicho nada acerca de la consistencia o inconsistencia de SQL.
Claro, seguro que no, era lo que faltaba por leer. Es la primera vez
que aparecen esas palabras en todo el hilo.
>Lo de los 850.000$ no fue un ejemplo: fue una anécdota.
Tú eres el que dice que para ti lo único importante son las anécdotas.
Pero claro, solo valen tus anécdotas, las de los demás tampoco sirven.
> Los problemas derivados de permitir nulos en ciertas
>columnas van a ocurrir de cualquier manera
Hasta tu mismo has explicado que cuando se añade un where is not null
a algunos de mis ejemplos los problemas desaparecen. Menuda
desfachatez.
Y del evidente problema de que para un ser humano es mucho más fácil
equivocarse cuando hay 19683 operadores que cuando hay 16 nunca has
dicho nada y te has preocupado de borrarlo de todas tus citas.
Que los nulos causan muchos errores en la práctica es un hecho
incontrovertible. Cualquiera que haya trabajado una temporada con
bases de datos lo sabe de sobra. La teoría nos sirve para explicar por
que pasa eso que vemos tan a menudo y proporcionarnos soluciones.
>Si en vez de insultarme o apabullarme con dogmas intentaras darme un
>ejemplo que demuestre (pero que realmente demuestre) que es mejor partir las
>tablas que permitir nulos, estaría dispuesto a reconocer mi error.
Ahí está tu truco, nunca admitirás que algo "realmente" lo demuestra.
Por que demostradísimo ya quedó.
>De momento, si escribo SELECT * FROM X y me encuentro que en la columna C de
>una tupla hay un NULL, entiendo de inmediato que el valor de C no está
>disponible para esa tupla. Tu dogma requiere que vea si en Z existe un
>registro donde Z.PK = X.PK para saber si el valor de C está o no está
>disponible, o que reemplace el select anterior por SELECT X.*, Z.C FROM X
>LEFT JOIN Z ON X.Clave = Z.Clave, para obtener lo mismo (incluyendo el NULL)
>que habría obtenido con el primer select.
Ya hemos hablado de COALESCE. Además de falta de entendimiento tienes
malicia. Así que te meto en el filtro anti trolls.