Relaciones 0..1 a 0..*

Hola, no entiendo eso de agragar a que te referis!! yo las relaciones las
manejo con los JOIN y nunca tuve problemas de performance


Salu2
Maxi


"Codigo47" escribió en el mensaje
news:

Queria saber como manejan ustedes las relaciones ?, y si permiten que haya
relaciones de tipo "De Cero o 1 a Cero o Muchos"

Encontré en este foro personas que agregar un registro con leyendas como
"Otro", "General", etc. Para no tener que usar este tipo de relacion. Y
argumentan que mejora la performance a la hora de hacer Joins entre
tablas.

Gracias.

Yo uso nulls las relaciones 1 a muchos siempre hago que la parte del 1 sea
obligatoria pero más que por otra cosa por que es un lio poner claves única
que admitan nulos.

Saludos
Miguel Egea

"Codigo47" escribió en el mensaje
news:

Queria saber como manejan ustedes las relaciones ?, y si permiten que haya
relaciones de tipo "De Cero o 1 a Cero o Muchos"

Encontré en este foro personas que agregar un registro con leyendas como
"Otro", "General", etc. Para no tener que usar este tipo de relacion. Y
argumentan que mejora la performance a la hora de hacer Joins entre
tablas.

Gracias.

Hola:
La logica de los nulos en SQL que 0..1 >0-* sea complicada.
Un ejemplo practico, puede ser que en la tabla de clientes, la columna
nacionalidad tenga referencia a la tabla Naciones,
Pero que pasa si el sistema permite no conocer la nacionalidad de un
cliente? (Este el el 0 del 0..1).
Estrictamente hablando es posible implementarlo si permitimos nulos en
la Tabla Clientes.
Algo como:
CREATE TABLE Clientes(
CodigoCliente INT NOT NULL PRIMARY KEY
, ... Otras Columnas
, Nacionalidad CHAR(3) NULL
FOREIGN KEY REFERENCES Naciones(CodigoNacion)
)
Esta tabla tiene el problema que cuando hacemos un JOIN con los clientes
"desaparecen" los clientes sin nacionalidad y si hacemos un LEFT/RIGTH JOIN,
en el SELECT es probable que no querramos que a la estacion lleguen nulos y
llenemos usando COALESCE o ISNULL para generar blancos. Por ultimo deben
tenerse cuidado con las condiciones del WHERE porque si quiero una lista de
los clientes no argentinos tengo que escribir WHERE (Nacionalidad<>'ARG' OR
Nacionalidad IS NULL). Esto puede destruir el uso de los indices.
Es posible (recomendable?) cambiar la representacion de esto. Si se crea
una nacion con codigo desconocido o invalido que implique otras
nacionalidades. Entonces se cambia la tabla por

,Nacionalidad CHAR(3) NOT NULL
FOREIGN KEY REFERENCES Naciones(CodigoNacion)
DEFAULT('000') -- 000 = Nacionalidad Desconocida/Otras
Nacionalidades
...
Mi opinion es:
a) No hay beneficios en el JOIN.
b) Hay algunos beneficios en los WHERE.
c) Hay beneficios en la escritura del codigo.
Mi voto es positivo. :D


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Maxi" wrote in message
news:

Hola, no entiendo eso de agragar a que te referis!! yo las relaciones las
manejo con los JOIN y nunca tuve problemas de performance


Salu2
Maxi


"Codigo47" escribió en el mensaje
news:
> Queria saber como manejan ustedes las relaciones ?, y si permiten que

haya

> relaciones de tipo "De Cero o 1 a Cero o Muchos"
>
> Encontré en este foro personas que agregar un registro con leyendas como
> "Otro", "General", etc. Para no tener que usar este tipo de relacion. Y
> argumentan que mejora la performance a la hora de hacer Joins entre
> tablas.
>
> Gracias.
>
>

Gracias Javier por la explicacion :), coincido contigo en la implementacion
que propones :)


Salu2
Maxi


"Javier Loria" escribió en el mensaje
news:

Hola:
La logica de los nulos en SQL que 0..1 >0-* sea complicada.
Un ejemplo practico, puede ser que en la tabla de clientes, la columna
nacionalidad tenga referencia a la tabla Naciones,
Pero que pasa si el sistema permite no conocer la nacionalidad de un
cliente? (Este el el 0 del 0..1).
Estrictamente hablando es posible implementarlo si permitimos nulos en
la Tabla Clientes.
Algo como:
CREATE TABLE Clientes(
CodigoCliente INT NOT NULL PRIMARY KEY
, ... Otras Columnas
, Nacionalidad CHAR(3) NULL
FOREIGN KEY REFERENCES Naciones(CodigoNacion)
)
Esta tabla tiene el problema que cuando hacemos un JOIN con los
clientes
"desaparecen" los clientes sin nacionalidad y si hacemos un LEFT/RIGTH
JOIN,
en el SELECT es probable que no querramos que a la estacion lleguen nulos
y
llenemos usando COALESCE o ISNULL para generar blancos. Por ultimo deben
tenerse cuidado con las condiciones del WHERE porque si quiero una lista
de
los clientes no argentinos tengo que escribir WHERE (Nacionalidad<>'ARG'
OR
Nacionalidad IS NULL). Esto puede destruir el uso de los indices.
Es posible (recomendable?) cambiar la representacion de esto. Si se
crea
una nacion con codigo desconocido o invalido que implique otras
nacionalidades. Entonces se cambia la tabla por

,Nacionalidad CHAR(3) NOT NULL
FOREIGN KEY REFERENCES Naciones(CodigoNacion)
DEFAULT('000') -- 000 = Nacionalidad Desconocida/Otras
Nacionalidades
...
Mi opinion es:
a) No hay beneficios en el JOIN.
b) Hay algunos beneficios en los WHERE.
c) Hay beneficios en la escritura del codigo.
Mi voto es positivo. :D


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda

"Maxi" wrote in message
news:

Hola, no entiendo eso de agragar a que te referis!! yo las relaciones las
manejo con los JOIN y nunca tuve problemas de performance


Salu2
Maxi


"Codigo47" escribió en el mensaje
news:
> Queria saber como manejan ustedes las relaciones ?, y si permiten que

haya

> relaciones de tipo "De Cero o 1 a Cero o Muchos"
>
> Encontré en este foro personas que agregar un registro con leyendas
> como
> "Otro", "General", etc. Para no tener que usar este tipo de relacion. Y
> argumentan que mejora la performance a la hora de hacer Joins entre
> tablas.
>
> Gracias.
>
>