FK surrogada NULL o cero?

Hola Carlos,

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

Los diseñadores de SQL Server (o cualquier otro SGBD SQL) solo
sabían lo que le dieron hecho los diseñadores de SQL (y las teorías
del gran Codd).

SQL se diseñó sobre la marcha para el System R y sus diseñadores no tenían
experiencia ni muchos conocimientos sobre diseño de lenguajes por que no
era su especialidad.

Estos a su vez *quizás* pensaron, ante el problema
de que puede faltar información, que un diseño lógico correcto daría
lugar a muchas tablas.

Yo creo que simplemente les pareció que los nulos eran una buena idea, por
que nadie los había probado antes y no se había visto lo malos que eran.

El System R era solo un experimento para saber si el Modelo Relacional
servía para algo. Y el resultado del experimento fue que el Modelo
Relacional si servía, pero el SQL les quedó como un churro. Habían
intentado hacer un lenguaje para tontos, es decir lo menos matemático
posible, pero no les salía y entonces dieron marcha atrás, pero a medias, y
les quedó de pena.

El siguiente paso sería volver a empezar desde 0 aprendiendo de los
errores, pero Larry Ellison se les adelantó sacando al mercado un producto
basado en SQL, y todavía seguimos sufriendo las consecuencias.


Saludos

Hola Alfredo,

On 15 sep, 16:29, Alfredo Novoa wrote:

Hola Carlos,

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

> Los diseñadores de SQL Server (o cualquier otro SGBD SQL) solo
> sabían lo que le dieron hecho los diseñadores de SQL (y las teorías
> del gran Codd).

SQL se diseñó sobre la marcha para el System R y sus diseñadores no tenían
experiencia ni muchos conocimientos sobre diseño de lenguajes por que no
era su especialidad.

> Estos a su vez *quizás* pensaron, ante el problema
> de que puede faltar información, que un diseño lógico correcto daría
> lugar a muchas tablas.

Yo creo que simplemente les pareció que los nulos eran una buena idea, por
que nadie los había probado antes y no se había visto lo malos que eran.

El System R era solo un experimento para saber si el Modelo Relacional
servía para algo. Y el resultado del experimento fue que el Modelo
Relacional si servía, pero el SQL les quedó como un churro. Habían
intentado hacer un lenguaje para tontos, es decir lo menos matemático
posible, pero no les salía y entonces dieron marcha atrás, pero a medias, y
les quedó de pena.

El siguiente paso sería volver a empezar desde 0 aprendiendo de los
errores, pero Larry Ellison se les adelantó sacando al mercado un producto
basado en SQL, y todavía seguimos sufriendo las consecuencias.

Ya sé que empezaron con las ideas de Codd sobre los, yo qué sé
cuantos tipos de *marks*. No me está claro en qué punto se dieron
cuenta a ciencia cierta que no era buena idea.

En cuanto a lo de Larry Ellison... es típico. Tecnologías que
llegan al mercado porque se copia, se copia y se vuelve a copiar
con el unico entendimiento de los dólares que le nublan a uno
la vista.
Para estar ahora discutiendo sobre que es lo que sabe SQL Server!

Saludos,
Carlos

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

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

Yo me refería los null's en un campo de una clave foránea. Creo que era el
tema de que hablaba Pablo. Mencioné agregados pensando en el group by no
en
el Sum y hablé de joins pensando en dichas relaciones.


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


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

Bueno, aún en eso debes tener en mente usar ISNULL(), COALESCE(), etc.
cuando sea necesario. O, si no es realmente necesario tener campos
numéricos definidos a que admitan NULL (yo de hecho es muy raro que permita
NULL en campos numéricos de los que mencionas), marcar ese campo como NOT
NULL y ponerle un DEFAULT VALUE en cero.

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

Puede que no sea más obvio, pero su ventaja es discutible.

>Con los null, por arte de magia y la equivocación de alguno no se
>volverían a ver jamás.

La equivocación de alguno no creo que sea argumento.
Nos equivocamos hasta en los diseños.


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

Puede que sea más propenso a errores en algunos casos, que no creo sean de
más alto nivel, ni tal cosa sea la norma. Tendría que ver pruebas de eso
para aceptarlo.

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

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

Por qué tengo la impresión que traes de nuevo del pelo un ejemplo hecho a la
medida para no "perder" la discusión ? Aquí no se trata ganar o perder.

Creo que ya os voy conociendo :)

Pues mejor di "desconocido". Es difícil definir un concepto como el de
NULL.

Es difícil por que es un concepto que está muy liado, y en el estandar SQL
es inconsistente. La definición más habitual es que un nulo es una marca
que indica falta de valor.

Pero estoy seguro que entiendes lo que quise decir, igual que Carlos.

Ahora lo he entendido, antes no. Cuando se habla de estas cosas tan liosas
es importante ser muy preciso por que sino cada uno puede entender una
cosa
diferente.

Bueno, en eso tienes toda la razón. Disculpas si se ha malinterpretado mi
mensaje.

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

Yo creo que en cierta forma estamos hablando de lo mismo.

"Alfredo Novoa" escribió en el mensaje
news:qpm1203gc706$.plq4049zc42e$

El Mon, 15 Sep 2008 14:08:30 +0200, Alfredo Novoa escribió:

O los Outer Join's son también un error? Verdad que no?

No, pero rellenar con nulos si que es un gran error.

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


Saludos