Es incorrecto el uso de null

"Alfredo Novoa" escribió en el mensaje
news:

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!

Hola Leonardo,

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.

Hola Leonardo,

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" escribió en el mensajenews:

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

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.

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.

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.

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

Hola Alfredo,

On 2 dec, 15:24, Alfredo Novoa wrote:

On 2 dic, 09:29, "Carlos M. Calvelo" 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

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
On Sun, 25 May 2003 17:35:17 GMT, (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"
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" 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.