🚀 go-pugleaf

Hola:

F. Serrano wrote:

> Zahori wrote:
> 
> 
> Ante todo gracias, aunque ��ste es el grupo adecuado para esta
> consulta? (viene de ecol.misc).
> 
> 
>>        Lo que tienes que hacer es incluir el campo que es clave de
>>una tabla en la otra (u otras) con la(s) que este relacionada.
>>
> 
> Si, eso lo tengo claro, lo que no tengo claro es c�mo se hace.
> 


En otro mensaje ya contest� a esto.


> 
> Sacado del manual de mysgl:
> 
> --------------------------------------
> 
> 1.4.4.5 Foreign Keys
 

[...]


> The FOREIGN KEY syntax in MySQL exists only for compatibility with
> other SQL vendors' CREATE TABLE commands; it doesn't do anything. 
> 


...que era lo que yo dec�a.


> ...
> 
> "1.4.4.6 Reasons NOT to Use Foreign Keys constraints"
> 
> --------------------------------------
> 
> Es dedir, que no debes usar claves for�neas ????, y solo debes
> relacionar la forma de mostrar los datos, como indica el ejemplo??. �o
> se piede, pero no sirve de nada? 
> 


No.  Lo que dice es: otros motores usan claves externas, pero MySQL no. 
  Sin embargo, para que la gente pueda crear scripts de creaci�n de 
esquemas m�s f�cilmente, se admite la sintaxis FOREIGN KEY de manera 
que, por ejemplo, con el mismo script (por lo que ha este punto 
respecta) se pueda crear una base de datos en MySQL o en Postgre; sin 
embargo, la llamada a FOREIGN KEY no hace nada relevante.
En el siguiente cap�tulo que indicas (si la memoria no me falla) no se 
dice que no se deben usar claves externas, sino que dan razones *por las 
que ellos no las implementan* (b�sicamente, velocidad... aunque esto 
habr�a que verlo).


> 
> 
>>        Luego, si quieres explicitar mas esa relacion y hacer que se
>>cumplan las condiciones de integridad, en la tabla de libros tendrias
>>que annadir una clausula para indicarle que el campo cod_autor (o como
>>lo hayas llamado) esta relacionado con el campo Codigo de la tabla
>>Autores, aunque no se si en MySQL se seguira la sintaxis estandar.
>>


Ni est�ndar ni no est�ndar, porque esto no est� soportado.


> 
> Te refieres a:
> 
> --------------------------------------
> 3.5.6 Using Foreign Keys
> 
> ....
> 
> CREATE TABLE shirts (
>     id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
>     style ENUM('t-shirt', 'polo', 'dress') NOT NULL,
>     color ENUM('red', 'blue', 'orange', 'white', 'black') NOT NULL,
>     owner SMALLINT UNSIGNED NOT NULL REFERENCES persons,
>     PRIMARY KEY (id)
> );
> 
> --------------------------------------
> 
> En este ejemplo, �"owner" es la clave for�nea "id" de la tabla
> "persons" ?? ��si hago esto, se podr� actualizar (no solo mostrar)
> campos comunes de tablas relacionadas con alg�n front-end, o hay que
> aplicarse autodisciplina par que esto no deba hacerse? �Qu�
> ventajas-inconvientes tiene 


Como t� mismo indicas m�s arriba, llamar a una clave externa est� 
soportado *pero no hace nada*: es la autodisciplina del programador la 
que se encarga de ello (aunque bien es cierto que puede tomar ventaja 
del esquema de la base de datos para automatizar un tanto el proceso, 
por ejemplo, en un hipot�tico front-end gen�rico).


> usar la clave for�nea o no usarla en ese caso? (no tengo mucho
> problema con el ingl�s, pero m�s que verde, estoy amarillo-lim�n en
> este tema, as� que pido disculpas por lo "lamer" que puedan ser estas
> cuestiones).
> 


Puesto que MySQL soporta declarar una clave externa (aunque no haga nada 
con esa declaraci�n) yo dir�a que es *muy recomendable* utilizarla en la 
creaci�n de tablas: por un lado "autodocumenta" el esquema de la base de 
datos: en un vistazo al esquema ya sabes que el campo x de la tabla X 
depende del campo y de la tabla Y sin necesidad de recurrir a la 
documentaci�n del esquema que, probablemente, no exista o no est� puesto 
al d�a.  Por otra parte, facilitar�a una hipot�tica migraci�n de la base 
de datos a otro motor... que incluso podr�a ser una hipot�tica versi�n 
futura de MySQL que s� soportase claves externas.  Abundando a�n m�s, 
como te indico, puede ser utilizada esta informaci�n como referencia 
para alg�n programa de acceso a esta base de datos.
-- 
SALUD,
Jes�s
***
jesus_navarro@promofinarsa.es
***