Relaciones

Hola:
Si si hay otra forma, pero lo natural es relacionar basado en Llaves
Primarias. Lla otra forma es con llaves Unicas.
Hay que considerar que normalmente es una gran ventaja tener todas las
columnas de una llave primaria en las tablas referenciasdas porque
normalmente es muy facil hacer agrupamientos o filtros basados en ellas.
A pesar de esto algunas veces se hace demasiado largo el cuento y
podemos tener un impacto muy grande en el desemenpero, sobre todo cuando son
MUY MUY Largas.
Un ejemplo:
Tabla Llave Primaria
Pais CodigoISO3166
EstadoProvincia CodigoISO3166/CodigoEstado
CodigoCiudad CodigoISO3166/CodigoEstado/CodigoCiudad

Podria ocurrir que en la tabla cliente no querramos mantener
Pais/Estado/Ciudad como columnas para relacionar con la tabla Ciudad,
entonces podriamos agregar una columna:
=CREATE TABLE Clientes(
.
, CiudadID INT IDENTITY(1,1) -- Identity Opcional
NOT NULL UNIQUE
)
== Y en la Tabla Clientes no poner las columnas
CodigoPais/CodigoEstado/CodigoCiudad sino unicamente CiudadID. Estableciendo
la Relacion. Claro los Agrupamientos Geograficos ahora seran mucho mas
complicados lo mismo que los filtros basados en Geografia, pero si no son
muy frecuentes podria ser aceptable por la reduccio de espacio total en la
Tabla de Clientes.
Debes asegurarte que CiudadID NO QUEDE EXPUESTO a los Usuarios, para
evitar los problemas de falta de numeros consecutivos, falta de integridad,
problemas con auditorias y otros que produce este tipo de columnas.
Saludos,

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.

Pablo Fabian Savino escribio:

Y...sigo preguntando

no hay forma de crear relaciones entre campos que
no sena primarykey?

porque , como puede ser que si en una tabla tengo
3 PK y en otra 1 PK o 2PK no pueda hacer una realacion decente?
me parece ilogico meter en todas las tablas todas
las PK iguales de otra tabla para hacer una simple realcion!

o...ustedes que saben mas, que otra manera habria
de protejer los datos sin hacer relaciones?


Salute!

Hola Javier, gracias por la Info, decime, dende estas ? yo en Santa Ana :)
vos?

Saludos.!

"Javier Loria" wrote in message
news:%

Hola:
Si si hay otra forma, pero lo natural es relacionar basado en Llaves
Primarias. Lla otra forma es con llaves Unicas.
Hay que considerar que normalmente es una gran ventaja tener todas las
columnas de una llave primaria en las tablas referenciasdas porque
normalmente es muy facil hacer agrupamientos o filtros basados en ellas.
A pesar de esto algunas veces se hace demasiado largo el cuento y
podemos tener un impacto muy grande en el desemenpero, sobre todo cuando

son

MUY MUY Largas.
Un ejemplo:
Tabla Llave Primaria
Pais CodigoISO3166
EstadoProvincia CodigoISO3166/CodigoEstado
CodigoCiudad CodigoISO3166/CodigoEstado/CodigoCiudad

Podria ocurrir que en la tabla cliente no querramos mantener
Pais/Estado/Ciudad como columnas para relacionar con la tabla Ciudad,
entonces podriamos agregar una columna:
=> CREATE TABLE Clientes(
.
, CiudadID INT IDENTITY(1,1) -- Identity Opcional
NOT NULL UNIQUE
)
==> Y en la Tabla Clientes no poner las columnas
CodigoPais/CodigoEstado/CodigoCiudad sino unicamente CiudadID.

Estableciendo

la Relacion. Claro los Agrupamientos Geograficos ahora seran mucho mas
complicados lo mismo que los filtros basados en Geografia, pero si no son
muy frecuentes podria ser aceptable por la reduccio de espacio total en la
Tabla de Clientes.
Debes asegurarte que CiudadID NO QUEDE EXPUESTO a los Usuarios, para
evitar los problemas de falta de numeros consecutivos, falta de

integridad,

problemas con auditorias y otros que produce este tipo de columnas.
Saludos,

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.

Pablo Fabian Savino escribio:
> Y...sigo preguntando
>
> no hay forma de crear relaciones entre campos que
> no sena primarykey?
>
> porque , como puede ser que si en una tabla tengo
> 3 PK y en otra 1 PK o 2PK no pueda hacer una realacion decente?
> me parece ilogico meter en todas las tablas todas
> las PK iguales de otra tabla para hacer una simple realcion!
>
> o...ustedes que saben mas, que otra manera habria
> de protejer los datos sin hacer relaciones?
>
>
> Salute!

Hola:
Yo vivi en Santa Ana como 5 anos, en la Cooperativa Las Cabanas. Ahora
vivo en San Jose.
Saludos!


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.
Pablo Fabian Savino escribio:

Hola Javier, gracias por la Info, decime, dende estas ? yo en Santa
Ana :) vos?

Saludos.!

"Javier Loria" wrote in message
news:%

Hola:
Si si hay otra forma, pero lo natural es relacionar basado en
Llaves Primarias. Lla otra forma es con llaves Unicas.
Hay que considerar que normalmente es una gran ventaja tener
todas las columnas de una llave primaria en las tablas
referenciasdas porque normalmente es muy facil hacer agrupamientos o
filtros basados en ellas. A pesar de esto algunas veces se hace
demasiado largo el cuento y
podemos tener un impacto muy grande en el desemenpero, sobre todo
cuando son MUY MUY Largas.
Un ejemplo:
Tabla Llave Primaria
Pais CodigoISO3166
EstadoProvincia CodigoISO3166/CodigoEstado
CodigoCiudad CodigoISO3166/CodigoEstado/CodigoCiudad

Podria ocurrir que en la tabla cliente no querramos mantener
Pais/Estado/Ciudad como columnas para relacionar con la tabla Ciudad,
entonces podriamos agregar una columna:
=>> CREATE TABLE Clientes(
.
, CiudadID INT IDENTITY(1,1) -- Identity Opcional
NOT NULL UNIQUE
)
==>> Y en la Tabla Clientes no poner las columnas
CodigoPais/CodigoEstado/CodigoCiudad sino unicamente CiudadID.
Estableciendo la Relacion. Claro los Agrupamientos Geograficos ahora
seran mucho mas complicados lo mismo que los filtros basados en
Geografia, pero si no son muy frecuentes podria ser aceptable por la
reduccio de espacio total en la Tabla de Clientes.
Debes asegurarte que CiudadID NO QUEDE EXPUESTO a los Usuarios,
para evitar los problemas de falta de numeros consecutivos, falta de
integridad, problemas con auditorias y otros que produce este tipo
de columnas. Saludos,

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.

Pablo Fabian Savino escribio:

Y...sigo preguntando

no hay forma de crear relaciones entre campos
que no sena primarykey?

porque , como puede ser que si en una tabla
tengo 3 PK y en otra 1 PK o 2PK no pueda hacer una realacion
decente? me parece ilogico meter en todas las
tablas todas
las PK iguales de otra tabla para hacer una simple realcion!

o...ustedes que saben mas, que otra manera
habria de protejer los datos sin hacer relaciones?


Salute!