Respecto a PKs

Por cierto, se me acaba de ocurrir a toro pasado. Igual es que yo estoy
entendiendo mal el concepto de clave compuesta como una clave primaria
compuesta de dos columnas, y vosotros estáis hablando de crear un tipo
de datos que conste de dos miembros que sean NodoID, ID. Entonces no
habría problema a la hora de establecer claves foráneas.

Se admiten correcciones, ideas, etc.. y de antemano, perdón si os
parece muy básico lo que pregunto.

Un saludo

http://www.moondance.tk

On Mon, 31 Mar 2008 18:14:52 +0200, Juan Diego Bueno
wrote:

Hola Juan Diego,

Pues a mi me parece que está bastante mal. Los enteros suelen ser unos
identificadores bastante malos para los seres humanos.

Bueno, al menos en eso no lo estoy haciendo mal.

¿Quieres decir que usas identificadores alfanuméricos en el modelo
lógico cuando lo crees conveniente?

Eso está muy bien, y también el usar claves compuestas cuando venga
bien. Yo tengo tablas con claves de 7 atributos.

Esto es una muy mala práctica y una violación del principio de
información de Codd. Lo correcto es usar claves compuestas aunque sean
numéricas.

Es decir, tu propones al igual que Alejandro, una clave primaria
compuesta por dos campos: NodoID, ID

Claro.

¿pero no es un coñazo esto en
términos de claves foráneas?.

No, solo tardas un segundo más en crear la primera y luego usas copiar
y pegar y listo.

Y aunque lo fuese eso sería lo de menos.

Si yo hago referencia en otra tabla al
registro x, tengo que establecer una clave foránea doble para esto y me
parece un jaleo considerable.

¿Por tener que introducir 3 caracteres más?

No seas tan vago ;-), que luego ahorras mucho más trabajo por otro
lado :-D

Aunque claro, en un lenguaje mejor diseñado que SQL no haría falta
escribir más. Como por ejemplo en Tutorial D y D4.

Si mi nodo tiene un código sencillo, por
ejemplo, EB, no veo que hay de malo en que yo a un id de pedido le
llame EB-100 y lo contenga en una sola clave.

Pues es muy malo. Dale un repaso al libro de Date.

Por ejemplo es malo por que te va a obligar a usar la función
SubString para todo y te va a complicar las consultas y las
restricciones de integridad y va a facilitar que cometas errores.

Para recuperar el 100 tienes que hacer un
CAST(SUBSTRING(CAMPO,4,nosecuanto) as int) y esto si que es un coñazo
y no lo de la clave externa con 2 campos.

Me gustaría saber por qué
esto rompe dicho principio de información de Codd (no porque no lo
cuestione, sino porque no tengo muy claro en que consiste)

Consiste en que toda la información se debe de representar en forma de
relaciones y no se debe de codificar información compuesta dentro de
los valores de las tuplas ni guardar información en los nombres de los
atributos ni de las tablas.


Saludos
Alfredo

Hola Alejandro,

On Mon, 31 Mar 2008 07:33:01 -0700, Alejandro Mesa
wrote:

la
naturaleza randomica (no se si esta palabra existe en español - trato de
decir azar).

Menuda patada al diccionario ;-)

Podías haber dicho "naturaleza aleatoria" :-)


Saludos
Alfredo

Alfredo Novoa,

Gracias por la correccion. La palabra aleatoria no me vino en ese momento.

AMB

"Alfredo Novoa" wrote:

Hola Alejandro,

On Mon, 31 Mar 2008 07:33:01 -0700, Alejandro Mesa
wrote:

>la
>naturaleza randomica (no se si esta palabra existe en español - trato de
>decir azar).

Menuda patada al diccionario ;-)

Podías haber dicho "naturaleza aleatoria" :-)


Saludos
Alfredo

Hola Alfredo:

"Alfredo Novoa" escribió en el mensaje
news:

Hola Juan Diego,


¿Quieres decir que usas identificadores alfanuméricos en el modelo
lógico cuando lo crees conveniente?

Eso está muy bien, y también el usar claves compuestas cuando venga
bien. Yo tengo tablas con claves de 7 atributos.

Esto es una muy mala práctica y una violación del principio de
información de Codd. Lo correcto es usar claves compuestas aunque sean
numéricas.

Es decir, tu propones al igual que Alejandro, una clave primaria
compuesta por dos campos: NodoID, ID

Claro.

¿pero no es un coñazo esto en
términos de claves foráneas?.

No, solo tardas un segundo más en crear la primera y luego usas copiar
y pegar y listo.

Y aunque lo fuese eso sería lo de menos.

Si yo hago referencia en otra tabla al
registro x, tengo que establecer una clave foránea doble para esto y me
parece un jaleo considerable.

¿Por tener que introducir 3 caracteres más?

No seas tan vago ;-), que luego ahorras mucho más trabajo por otro
lado :-D

Aunque claro, en un lenguaje mejor diseñado que SQL no haría falta
escribir más. Como por ejemplo en Tutorial D y D4.

Ok, tomo nota para el futuro

Si mi nodo tiene un código sencillo, por
ejemplo, EB, no veo que hay de malo en que yo a un id de pedido le
llame EB-100 y lo contenga en una sola clave.

Pues es muy malo. Dale un repaso al libro de Date.

Por ejemplo es malo por que te va a obligar a usar la función
SubString para todo y te va a complicar las consultas y las
restricciones de integridad y va a facilitar que cometas errores.

Para recuperar el 100 tienes que hacer un
CAST(SUBSTRING(CAMPO,4,nosecuanto) as int) y esto si que es un coñazo
y no lo de la clave externa con 2 campos.

Pero es que yo el 100 ya lo tengo en otro campo, y compongo el valor de la
columna con ese campo y el otro código que te dije. Además, generalmente
nunca uso ese id numérico para las consultas, por lo tanto nunca necesito
hacer ningún substring ni similar. Si el problema es la redundancia, ya que
tengo una PK que vale EB-100 y otro campo que vale 100 y eso vulnera... no
recuerdo que forma normal (creo que la segunda) lo entiendo, pero por nada
más. Además, no suelo necesitar el número de orden del registro, con lo cual
podría generar ese id numérico e integrarlo en la columna que sirve de PK
sin necesidad de tenerlo en otro campo. Lo de la clave externa con dos
campos me complica mucho sobre todo a la hora de programar la aplicación
cliente y tener que utilizar dos claves foráneas. Por ejemplo, supongamos un
combo que me muestra datos de una tabla relacionada que tiene una clave
principal compuesta. Pensando en .NET, ese combo tiene un VALUEMEMBER y un
DISPLAYMEMBER ambos procedientes de diferentes campos de una tabla (ID,
DESCRIPCION). Así es simple, con una columna como clave principal, pero si
pensamos en una PK compuesta por NODOID, ID, ya tengo que recurrir a, como
mínimo un struct para reflejar eso, sin contar luego los problemas en
términos de databinding. No lo acabo de ver...

Me gustaría saber por qué
esto rompe dicho principio de información de Codd (no porque no lo
cuestione, sino porque no tengo muy claro en que consiste)

Consiste en que toda la información se debe de representar en forma de
relaciones y no se debe de codificar información compuesta dentro de
los valores de las tuplas ni guardar información en los nombres de los
atributos ni de las tablas.

Bueno, en estos correos creo que he dejado ver en qué lo cumplo y en qué no.

Saludos