Foros del Web » Programación para mayores de 30 ;) » Bases de Datos General » Mysql »

Para que son las relaciones de las tablas?

Estas en el tema de Para que son las relaciones de las tablas? en el foro de Mysql en Foros del Web. Se que se puede hacer para que se borre en cascada pero eso siempre lo hago en la programacion. no me ha sido muy util ...
  #1 (permalink)  
Antiguo 09/09/2012, 08:28
 
Fecha de Ingreso: agosto-2012
Ubicación: M.
Mensajes: 2.031
Antigüedad: 12 años, 2 meses
Puntos: 52
Para que son las relaciones de las tablas?

Se que se puede hacer para que se borre en cascada pero eso siempre lo hago en la programacion.
no me ha sido muy util eso
¿sera mas comodo?
a mi en lo particular se me ha hecho mas cómodo hacerlo en el programa que estar pensando en como unir las tablas.
el ultimo sistema que hice tenia 40 tablas que están relacionadas pero en la programacion, en el sql no.
pues se me hace mas comodo ya que en la programación en la consulta sql indico exactamente que quiero modificar y en las tablas de relaciones siento que se me puede pasar algo por error y borrarse algo que no quiera en cadena, ademas como que es mas dificil alterar una tabla relacionada.
ustedes que piensan, por que se les hace mas cómodo?
si quisiera saber cuales son las ventajas de usar relaciones
una ventaja que creo que es buena de no relacionar, es que si un intruso inyecta sql,este no afecta a todas las tablas relacionadas. hace un desastre pero no afecta a las demas(no se pierde toda la informacion)

y otra pregunta.

¿por que utilizar procedimientos almacenados en vez de usar la consulta sql directamente del programa?
  #2 (permalink)  
Antiguo 09/09/2012, 09:16
Avatar de gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 17 años
Puntos: 2658
Respuesta: Para que son las relaciones de las tablas?

Es una pregunta algo inesperada, y un poco asombrosa...
¿Crees que si el único motivo de relacionar tablas fuese hacer cascadas de borrados o actualizaciones, tendría algún sentido?
No.
La razón de la existencia de las relaciones no es sólo para eso. De hecho, eso es una consecuencia de las relaciones definidas en las bases de datos y no el origen de ellas.
Explicar el cómo y por qué se llegó a la definición de relaciones entre tablas es algo largo y mucho de la teoría necesita de buenos conocimientos de sistemas, pero una síntesis elemental se puede decir así: Consistencia de Datos, Integridad Referencial, Eliminación de Redundancias innecesarias y Normalización.

Una parte fundamental de la razón de la existencia de relaciones está en el aseguramiento de consistencia datos.
Sin las relaciones, un error de programación puede resultar en información basura por pérdida de consistencia, que es el caso que tienes diseñado: Manejar las relaciones programáticamente conlleva el riesgo de que un dato mal ingresado (que los hay) termine en un desastre contable.
Y con ello, tu puesto de trabajo.

Yo he visto suceder que un error de un proceso que no actualizó debidamente un campo en una tabla, generó la pérdida de dos años de datos de pagos en una empresa de seguros médicos. Y llevó catorce meses recuperar los datos reingresando manualmente otra vez todos los pagos. Meses perdidos.
Si hubiesen definido correctamente la relación, la primera vez que intentara acceder a ese campo con ese valor malo, simplemente el DBMS no le hubiera dejado hacerlo. El error hubiera sido evidente, y no habría estado sin detectarse hasta que hicieron la consolidación de datos.¿Te parece realmente que no sirven o son superfluas?

Uno de los problemas que tenemos quienes nos dedicamos al tema de las BBDD, es hacer que los desarrolladores (programadores) entiendan claramente la importancia de la arquitectura de datos. En general (y ese parece ser tu caso) no lo ven, porque ellos ven procesos, y nosotros vemos datos. Son lógicas distintas, por extraño que te parezca.
Siempre suelo comentar que cuando mis profesores de BBDD me decían eso, me parecía una exageración, pero los años me han mostrado que estaban en lo cierto.

Es posible que más que otra cosa, te convenga estudiar un poco de los fundamentos de las bases de datos, para lo cual te recomendaría una mirada al libro de Codd llamado, precisamente, "Fundamentos de las Bases de Datos".
Es algo técnico, pero puede que te abra un poco la visión a los problemas que causan.
Hay otros libros, más accesibles, si te resulta complejo ese.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)
  #3 (permalink)  
Antiguo 09/09/2012, 12:45
 
Fecha de Ingreso: agosto-2012
Ubicación: M.
Mensajes: 2.031
Antigüedad: 12 años, 2 meses
Puntos: 52
Respuesta: Para que son las relaciones de las tablas?

Cita:
Iniciado por gnzsoloyo Ver Mensaje
Es una pregunta algo inesperada, y un poco asombrosa...
¿Crees que si el único motivo de relacionar tablas fuese hacer cascadas de borrados o actualizaciones, tendría algún sentido?
No.
La razón de la existencia de las relaciones no es sólo para eso. De hecho, eso es una consecuencia de las relaciones definidas en las bases de datos y no el origen de ellas.
Explicar el cómo y por qué se llegó a la definición de relaciones entre tablas es algo largo y mucho de la teoría necesita de buenos conocimientos de sistemas, pero una síntesis elemental se puede decir así: Consistencia de Datos, Integridad Referencial, Eliminación de Redundancias innecesarias y Normalización.

Una parte fundamental de la razón de la existencia de relaciones está en el aseguramiento de consistencia datos.
Sin las relaciones, un error de programación puede resultar en información basura por pérdida de consistencia, que es el caso que tienes diseñado: Manejar las relaciones programáticamente conlleva el riesgo de que un dato mal ingresado (que los hay) termine en un desastre contable.
Y con ello, tu puesto de trabajo.

Yo he visto suceder que un error de un proceso que no actualizó debidamente un campo en una tabla, generó la pérdida de dos años de datos de pagos en una empresa de seguros médicos. Y llevó catorce meses recuperar los datos reingresando manualmente otra vez todos los pagos. Meses perdidos.
Si hubiesen definido correctamente la relación, la primera vez que intentara acceder a ese campo con ese valor malo, simplemente el DBMS no le hubiera dejado hacerlo. El error hubiera sido evidente, y no habría estado sin detectarse hasta que hicieron la consolidación de datos.¿Te parece realmente que no sirven o son superfluas?

Uno de los problemas que tenemos quienes nos dedicamos al tema de las BBDD, es hacer que los desarrolladores (programadores) entiendan claramente la importancia de la arquitectura de datos. En general (y ese parece ser tu caso) no lo ven, porque ellos ven procesos, y nosotros vemos datos. Son lógicas distintas, por extraño que te parezca.
Siempre suelo comentar que cuando mis profesores de BBDD me decían eso, me parecía una exageración, pero los años me han mostrado que estaban en lo cierto.

Es posible que más que otra cosa, te convenga estudiar un poco de los fundamentos de las bases de datos, para lo cual te recomendaría una mirada al libro de Codd llamado, precisamente, "Fundamentos de las Bases de Datos".
Es algo técnico, pero puede que te abra un poco la visión a los problemas que causan.
Hay otros libros, más accesibles, si te resulta complejo ese.
Bueno de hecho asi es como dices.
sera que no he hecho programas que requieran altas relaciones, talvez.
pero bueno, ya vez que el usuario mete un dato mal y todo colapsa.
bueno como yo bloqueo los datos que el usuario no pueda meter entonces no hay problema.
solo dejo que el usuario capture los datos necesarios.

aunque tienes mucha razon, ahora que lo veo, el programa que estoy haciendo tiene un codigo de barras que puede ser modificado por el usuario y viendolo bien que si modifican ese codigo de barras tambien se deberia modificar el codigo de barras ese en todas las tablas donde exista. oO
cielos y eso nunca lo hice. bueno no creo que haya problema, muy dificil mente modifican un codigo de barras XD.
pero intentare hacer una relacion, aunque nose si despues me permita borrar, talvez sea un poco novato en eso de las relaciones y pues me ha tocado que relaciono y ya no puedo borrar por que ya hay datos en otro lado, no me deja mmm. pero lo probare
gracias
  #4 (permalink)  
Antiguo 09/09/2012, 12:49
Avatar de pzin
Moderata 😈
 
Fecha de Ingreso: julio-2002
Ubicación: Islas Canarias
Mensajes: 10.489
Antigüedad: 22 años, 3 meses
Puntos: 2114
Respuesta: Para que son las relaciones de las tablas?

http://es.wikipedia.org/wiki/Punto_(...Tipos_de_punto
  #5 (permalink)  
Antiguo 09/09/2012, 12:53
 
Fecha de Ingreso: agosto-2012
Ubicación: M.
Mensajes: 2.031
Antigüedad: 12 años, 2 meses
Puntos: 52
Respuesta: Para que son las relaciones de las tablas?

Cita:
Iniciado por Bonez Ver Mensaje
[url]http://es.wikipedia.org/wiki/Punto_(puntuaci%C3%B3n)#Tipos_de_punto[/url]
jajja, escribo bien cuando estoy en foros de literatura XD :D
aqui lo que si escribo bien es la sintaxys de programacion cuando hago referencias de un codigo XD
  #6 (permalink)  
Antiguo 09/09/2012, 12:54
 
Fecha de Ingreso: agosto-2012
Ubicación: M.
Mensajes: 2.031
Antigüedad: 12 años, 2 meses
Puntos: 52
Respuesta: Para que son las relaciones de las tablas?

mysql error Number 1005
can't create table (errno. 150)

cielos. no puedo crear la relacion :S
  #7 (permalink)  
Antiguo 09/09/2012, 13:01
Avatar de pzin
Moderata 😈
 
Fecha de Ingreso: julio-2002
Ubicación: Islas Canarias
Mensajes: 10.489
Antigüedad: 22 años, 3 meses
Puntos: 2114
Respuesta: Para que son las relaciones de las tablas?

Cita:
Iniciado por minombreesmm Ver Mensaje
jajja, escribo bien cuando estoy en foros de literatura XD :D
Un argumento muy pobre.

De todas formas también son normas de por aquí el escribir bien.
  #8 (permalink)  
Antiguo 09/09/2012, 13:14
 
Fecha de Ingreso: agosto-2012
Ubicación: M.
Mensajes: 2.031
Antigüedad: 12 años, 2 meses
Puntos: 52
Respuesta: Para que son las relaciones de las tablas?

uuuu es la tercera vez que trato de editar y no me deja que por que ya hay otro mensaje :S y aparte me pierde lo que escribi :S(se deberia guardar en una variable esa info y luego regresartela para que puedas continuar con lo que escribes) bueno en fin.

bueno escribo de nuevo
intento hacer la relacion pero me vota esto

mysql error Number 1005
can't create table (errno. 150)
quiero relacionar la tabla articulos con la tabla ventas y
y es que le doy en foreing key luego en el signo de + y agrego con el mismo nombre, luego en table ref, elijo la tabla que quiero relaciona y los campos que quiero relacionar. elijo codigo de barras de cada tabla que tienen el mismo nombre.
luego me marca el error y no deja :S
no es la primera vez, desde siempre que he intentado hacer eso me ha ocurrido lo mismo, por eso no me meto con eso mucho. mas vale no meterme en problemas con las bases de datos.
cuando quieren un sistema en una semana.
pero bien, ando batallando con eso ahorita. ya que tengo un dia para entregar, quisiera entregarlo ya con las relaciones.
pero eso no me deja :S
posdata
la tabla ventas esta vacia
y la tabla articulos esta llena
sospecho que las dos deben estar vacias para que funcione :S y si es asi entonces el resto de mis programas que ya usan los clientes estan perdidos :S

Reposdata
me considero un poco experto en selects y combinar tablas y todo eso, pues eso casi no me ha dado problema nunca.
pero eso de relacionar tablas internamente con foreings keys no es mi fuerte.

http://foro.elhacker.net/bases_de_datos/iquestes_recomendable_usar_foreign_key_en_mysql-t320748.0.html vaya hay mas gente con mis dudas

Última edición por minombreesmm; 09/09/2012 a las 13:33
  #9 (permalink)  
Antiguo 09/09/2012, 14:23
 
Fecha de Ingreso: agosto-2012
Ubicación: M.
Mensajes: 2.031
Antigüedad: 12 años, 2 meses
Puntos: 52
Respuesta: Para que son las relaciones de las tablas?

lo raro es que ya lo probe creando otras dos tablitas, y alli si funciona y aca no, y no se por que :S
  #10 (permalink)  
Antiguo 09/09/2012, 14:32
 
Fecha de Ingreso: agosto-2012
Ubicación: M.
Mensajes: 2.031
Antigüedad: 12 años, 2 meses
Puntos: 52
Respuesta: Para que son las relaciones de las tablas?

ya yaaaa ya entendi. debo tener vacia la tabla en la que quiero hacer la relacion a las otras.
supongo que esa es la principal.
  #11 (permalink)  
Antiguo 09/09/2012, 15:03
Avatar de gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 17 años
Puntos: 2658
Respuesta: Para que son las relaciones de las tablas?

Cita:
Iniciado por minombreesmm Ver Mensaje
mysql error Number 1005
can't create table (errno. 150)

cielos. no puedo crear la relacion :S
Ese es un mensaje error comun cuando se intenta crear una FK y la tabla tiene datos. Suele pasar cuando hay inconsistencia de datos y/o tipos de columna inconsistentes entre OK y FK.. Puede haber otros problemas más, cono error en el nombre de la constraint.
Que tenga datos no es problema. Es que hay datos mal cargados... Como suelen pasar.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)
  #12 (permalink)  
Antiguo 09/09/2012, 15:38
 
Fecha de Ingreso: agosto-2012
Ubicación: M.
Mensajes: 2.031
Antigüedad: 12 años, 2 meses
Puntos: 52
Respuesta: Para que son las relaciones de las tablas?

Cita:
Iniciado por gnzsoloyo Ver Mensaje
Ese es un mensaje error comun cuando se intenta crear una FK y la tabla tiene datos. Suele pasar cuando hay inconsistencia de datos y/o tipos de columna inconsistentes entre OK y FK.. Puede haber otros problemas más, cono error en el nombre de la constraint.
Que tenga datos no es problema. Es que hay datos mal cargados... Como suelen pasar.
Datos mal cargados? a que te refieres? o por que podria ocurrir eso oO.

mi duda es que quiero relacionar dos simples tablas, ya las vacie para que no haya problemas.
tabla productos
y tabla ventas
cuando vendo
se guarda en la tabla ventas, los datos de venta y el campo codigodebarras que es el mismo que tiene la tabla productos
¿como hago en el mysqlquerybrowser para que si modifico el codigodebarras en la tabla producto tambien se modifique el mismo codigodebarras que tengo en la tabla ventas?
tomando en cuenta que la tabla ventas puede tener repetido el codigo de barras y en la tabla productos no se debe repetir.
la entiendo como relacion 1 : M
pero no se que estoy haciendo mal :(
eh estado batallando mucho.
de antemano gracias
  #13 (permalink)  
Antiguo 09/09/2012, 16:59
Avatar de gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 17 años
Puntos: 2658
Respuesta: Para que son las relaciones de las tablas?

Empecemos por el principio:

El error 150 se produce simplemente porque algún inconveniente impidió crear la tabla, modificarla, o bien crear algún indice o constraint index de algún tipo. En esencia, lo principal es que fue una acción que implicó escribir un archivo descriptor de estructura. El cuál sea, depende de lo que se encuentre.
Hay algunas razones comunes para el error:
Se intentó establecer una FK que entre campos que no cumplen las condiciones:
- Tipos de columna incompatibles, como numéricos de diferente rango, tipos mezclados, o con collations diferentes. El primer caso es, por ejemplo, que uno sea sólo INT y el otro INT UNSIGNED, lo que daría un error por diferentes rangos de representación. El último caso se produce cuando usas un VARCHAR de collation utf8 y otro latin1, por ejemplo.
- Datos inválidos en la tabla, en el campo definido como FK. Al crear la FK una de las primeras cosas que hace el sistema es verificar si la tabla donde está la FK contiene en ese campo algún valor que no se encuentre presente en la tabla referenciada (donde ese valor es PK). Es el error más habitual al modificar tablas que ya contienen datos, precisamente porque antes no tuvieron consistencia sostenida desde el DBMS, y se ingresaron datos basura.
- Incompatibilidad de motores de tablas: Se intenta definir FK en una tabla que es MyISAM y otra InnoDB.
- Nombres de consrtaint solapados: Se ingresó el nombre de la constraint al momento de crear la FK, pero se usó algún nombre que ya existía en la base, usado por otro componente.
- FK refiriendo a campos no PK o UNIQUE en la tabla referida. Una FK sólo puede apuntar a una PK. Excepcionalmente, MySQL admite que se apunte a un campo que es UNIQUE en esa tabla, aunque no sea la PK (en los hechos es una CC).

En tu caso, si el error se sigue produciendo con las tablas vacías, sólo se puede excluir el tema de los datos, pero hay que revisar todas las otras posibilidades.

Cita:
¿como hago en el mysqlquerybrowser para que si modifico el codigodebarras en la tabla producto tambien se modifique el mismo codigodebarras que tengo en la tabla ventas?
Para eso se le pone a la definición de FK la cláusula ON DELETE CASCADE ON UPDATE CASCADE. Pero atención: todas, absolutamente todas las veces que se use la FK, deberá en esa tabla estár incluida esta cláusula, ya que la misma sólo se define para una tabla en especial, y no es generico.
Cita:
pero bien, ando batallando con eso ahorita. ya que tengo un dia para entregar, quisiera entregarlo ya con las relaciones.
¿Un día para entregar?


Considerando que es algo que debería haber estado desde el inicio, y que afectará completamente la performance de toda la base...



Deberías haberte asesorado antes. Ahora... sólo puedo desearte lo mejor.
Con un día no tenemos ni para hacer las primeras pruebas.


Nota bene: Una de las cosas que me olvidé aclararte al principio, es que otra de las características de la presencia de las FK es que las consultas pueden llegar a tener una performance muy diferente, porque el uso de las relaciones definidas como FK ayuda en toda consulta donde se usen, ya que esas FK se controlan por índices específicos... los que mejoran muchísimo la performance.
O sea... hay más razones.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)
  #14 (permalink)  
Antiguo 09/09/2012, 22:39
 
Fecha de Ingreso: agosto-2012
Ubicación: M.
Mensajes: 2.031
Antigüedad: 12 años, 2 meses
Puntos: 52
Respuesta: Para que son las relaciones de las tablas?

Cita:
Iniciado por gnzsoloyo Ver Mensaje
Empecemos por el principio:

El error 150 se produce simplemente porque algún inconveniente impidió crear la tabla, modificarla, o bien crear algún indice o constraint index de algún tipo. En esencia, lo principal es que fue una acción que implicó escribir un archivo descriptor de estructura. El cuál sea, depende de lo que se encuentre.
Hay algunas razones comunes para el error:
Se intentó establecer una FK que entre campos que no cumplen las condiciones:
- Tipos de columna incompatibles, como numéricos de diferente rango, tipos mezclados, o con collations diferentes. El primer caso es, por ejemplo, que uno sea sólo INT y el otro INT UNSIGNED, lo que daría un error por diferentes rangos de representación. El último caso se produce cuando usas un VARCHAR de collation utf8 y otro latin1, por ejemplo.
- Datos inválidos en la tabla, en el campo definido como FK. Al crear la FK una de las primeras cosas que hace el sistema es verificar si la tabla donde está la FK contiene en ese campo algún valor que no se encuentre presente en la tabla referenciada (donde ese valor es PK). Es el error más habitual al modificar tablas que ya contienen datos, precisamente porque antes no tuvieron consistencia sostenida desde el DBMS, y se ingresaron datos basura.
- Incompatibilidad de motores de tablas: Se intenta definir FK en una tabla que es MyISAM y otra InnoDB.
- Nombres de consrtaint solapados: Se ingresó el nombre de la constraint al momento de crear la FK, pero se usó algún nombre que ya existía en la base, usado por otro componente.
- FK refiriendo a campos no PK o UNIQUE en la tabla referida. Una FK sólo puede apuntar a una PK. Excepcionalmente, MySQL admite que se apunte a un campo que es UNIQUE en esa tabla, aunque no sea la PK (en los hechos es una CC).

En tu caso, si el error se sigue produciendo con las tablas vacías, sólo se puede excluir el tema de los datos, pero hay que revisar todas las otras posibilidades.

Para eso se le pone a la definición de FK la cláusula ON DELETE CASCADE ON UPDATE CASCADE. Pero atención: todas, absolutamente todas las veces que se use la FK, deberá en esa tabla estár incluida esta cláusula, ya que la misma sólo se define para una tabla en especial, y no es generico.
¿Un día para entregar?


Considerando que es algo que debería haber estado desde el inicio, y que afectará completamente la performance de toda la base...



Deberías haberte asesorado antes. Ahora... sólo puedo desearte lo mejor.
Con un día no tenemos ni para hacer las primeras pruebas.


Nota bene: Una de las cosas que me olvidé aclararte al principio, es que otra de las características de la presencia de las FK es que las consultas pueden llegar a tener una performance muy diferente, porque el uso de las relaciones definidas como FK ayuda en toda consulta donde se usen, ya que esas FK se controlan por índices específicos... los que mejoran muchísimo la performance.
O sea... hay más razones.
Bueno tengo que entregar en un dia por que asi lo dije, pero no esta firmado ningun contrato asi que puedo tardarme otros 3 o 5 dias .
y bien entonces la conclusion es que debo hacer todas las relaciones antes de llenar de datos las tablas.

y bien lo de update cascade lo probe

solo que solo me dejaba añadir un registro de esa misma clave en la tabla secundaria.

hice esto.
tabla productos
id(pk)
codigobarras(clavequecompartire)
Descripcion


tabla ventas
id(pk)
codigobarras
Folio

aqui en esta segunda tabla añado un foreingkey
donde elijo la tabla productos y relaciono el campo codigobarras con el campo codigobarras de producto.

lo hizo bien y todo.
ahora añado 3 productos
luego hago la venta de 3
oks los añado bien y todo
pero cuando quiero volver a vender uno de ellos
ya no se pueden añadir(iimagino por que no se pueden repetir)
pues la intencion es que la tabla ventas lo repita, ya que puede haber muchos folios con esa venta.
de antemano gracias

Etiquetas: procedimiento, relaciones, tabla, almacenar
Atención: Estás leyendo un tema que no tiene actividad desde hace más de 6 MESES, te recomendamos abrir un Nuevo tema en lugar de responder al actual.
Respuesta




La zona horaria es GMT -6. Ahora son las 08:04.