relacionar mas de 1 campo

[hanscruz]

Pues eso, quiero relacionar mas de un campo padre pero por mas que lo intento no puedo hacerlo, me explico:

Tengo una tabla llamada clientes y otra llamada ventas (clasico no) las tablas tienen estos campos:




Pues lo que deseo es que ademas de la Relacion del IdCliente que me funciona perfectamente, quiero que tambien este relacionado el campo NombreCliente, para cuando se cambie o actualize el campo NombreCliente en la tabla clientes automaticamente se actualize en la tabla ventas tambien.

Ya he intentado volviendo PK a NombreCliente tanto en un mismo indice como por separado pero nada no consigo establecer esa relacion.

Por favor no me hablen de la normalizacion que ya la tengo clara solo que si tengo que hacerlo de esa forma, ademas es solo un ejemplo que les pongo para que puedan guiarme ya que mis tablas no son tan cortas y sencillas como estas.

Gracias y espero sus respuestas.

[gnzsoloyo]

¿Y para qué quieres guardar en la tabla VENTA el nombre del cliente?
Eso no tienen ninguna utilidad desde el momento en que ese dato ya se encuentra en la tabla CLIENTE. Precisamente por ese tipo de detalles existe el modelo relacional: para mantener la consistencia y evitar la redundancia de datos. Y ese dato así como lo pones es redundante.
Si lo quieres para que luego salga en un listado, la consulta que genera el listado usa un JOIN entre ambas, lo que te permite obtener ese dato.
Por eso no se guarda en VENTAS.

Ahora bien, si lo que necesitas es hacer un REPORTE, los reportes no se guardan con FK de ningún tipo: Se generan con sus datos terminados y sin referenciación, ya que no se necesitan por ser históricos.

Fuera de eso te aclaro un detalle: Es imposible crear una relación de dependencia entre un campo cualquiera de una taba y un campo no clave de otra tabla.
¿Se comprende el problema?

Explicame, entonces, por qué necesitas que ese campo tenga esa dependencia, porque no se comprende.

[hanscruz]

Primero que nada gracias por responder.

Y si me aclaraste algunas dudas y si tienes razon se muy bien sobre la redundancia por eso pedi que no me hablaran sobre normalizacion de bd ya que lo entendi, pero la razon principal por la que quiero que ese dato tenga dependencia es que no deseo que cada ves que haga una consulta en ventas tenga que ir a buscar a otra tabla ya que solo por un dato consultar a otra tabla para obtener esos datos me parece mucho, ya que las consultas seran continuas casi una tras otra, en cambio la actualizacion de ese dato sera esporadica, pero necesito que cuando se actualize en la tabla cliente se actualizen en todos los registros de la tabla ventas.

Ahora si bien te entendi no se puede relacionar un campo con otro si este ultimo no es Primary Key, okey tambien lo sabia pero estaba investigando y resulta que el indice Primary Key puede tener mas de un campo con lo que se lograria tener mas campos con Primary Key, con lo que talves se podria lograr lo que quiero.

Ahora bien si estoy equivocado y se podria hacer de otra forma pues te agradeceria que me eches una mano o una sugerencia de como hacerlo segun lo que te explique, para las dos cosas:

1.- Que cuando el dato NombreCliente de la tabla clientes se actualize o incluso se elimine todos los campos NombreCliente (que son varchars) de los registros de la tabla ventas se actualizen o se eliminen tambien, osea en cascada, osea quedaria asi:



2.- Evitar que por solo un dato se tenga que consultar una tabla mas ya que las consultas seran continuas una tras otra (este ultimo para que sea mas rapida la respuesta de la base da datos), esta ultima duda me salio despues de leer un articulo en mysql-hispano en donde dicen que las relaciones no deben usarse cuando los campo a obtener son minimos como en este caso.

Gracias por responder nuevamente.

[gnzsoloyo]

- Antes que nada, no te ahogues sin haber nadado. Cruzar dos tablas donde la FK tiene una alta selectividad no produce un descenso de performance apreciable. En realidad, pierdes mas tiempo creando la conexión de lo que la base tarda en cruzar 45 tablas...

- Respecto a lo de MySQL Hispano, eso es un exceso de ortodoxia. Es cierto que debe evitarse la lectura repetitiva de tablas para obtener otros datos, pero eso no quiere decir eliminar las consultas repetitivas. Además, hay otras formas de resolver el problema sin llegar a necesitar aumentar la redundancia.

- Respecto a las PK multicampo, hay que tener cuidado con un detalle: No se crean PK en forma arbitraria, porque a la larga te generará muchísimos más problemas de performance, sin contar con inmensos problemas de integridad. Las PK forman índices agrupados, que son los que se usan para mantener el ordenamiento físico de los registros en el diso, y no solamente la identidad de los mismos. Eso signfica que cada vez que modificas una estructura de PK se produce un nuevo orden físico: los registros se reescriben y el índice también.
No hay que tratar las PK con liviandad.
Además de eso, el único sentido de usar una PK multicampo es si un sólo campo no identifica un registro, por lo que se necesita otro más para lograr una clave candidata. Y ese no es tu caso.

- Considera además este detalle: Si usas un ID autonumérico con un campo de texto como PK, con sólo cambiar una letra puedo usar el mismo numero para dos clientes distintos, o para el mismo cliente con dos escrituras diferentes... ¿Lo habías pensado?

- A mi entender y experiencia no vas a tener problemas de performance por tener que realizar ese cruce de tablas, por lo que todo el problema es irrelevante. Pon sólo el ID del cliente y resuelve el resto por JOIN.

- Si aún así quieres mantener esa forma redundante de datos, mejor manejalo con TRIGGERS, y no inventando claves que solamente te traerán problemas. No te olvides que cada clave primaria o foránea, es un índice que el DBMS debe mantener y actualizar... y eso sí afecta la performance del mismo.

[hanscruz]

Disculpa por no responder antes, pero la verdad me ayudaste mucho en tomar mis deciciones y cuando mencionaste los triggers pues investigue y en efecto esa es la solucion, los procedimientos de almacenado son una maravilla y me sirvieron muchisimo pues ahora lo tengo echo como queria desde un principio pero sin tener que relacionar ese campo, solo relaciono el Id, quedo perfecto.

Lo que hago es, lanzo un trrigger cuando se actualiza la tabla clientes y con los procedures actualizo los datos de la tabla facturas, me queda perfecto ya que estas actualizaciones se dan de forma esporadica, pero conservo los datos referenciales y la integridad de las los datos.

Gracias una ves mas.