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

Triple relación, dudas rendimiento y estructura

Estas en el tema de Triple relación, dudas rendimiento y estructura en el foro de Mysql en Foros del Web. Hola buenas de nuevo, Tengo la siguiente duda, Tengo tres tablas, usuarios, aplicaciones y aplicaciones_parametros Quiero que cada usuario pueda tener sus propios parámetros para ...
  #1 (permalink)  
Antiguo 08/02/2012, 03:19
 
Fecha de Ingreso: julio-2008
Ubicación: Barcelona
Mensajes: 2.100
Antigüedad: 16 años
Puntos: 165
Triple relación, dudas rendimiento y estructura

Hola buenas de nuevo,

Tengo la siguiente duda,

Tengo tres tablas, usuarios, aplicaciones y aplicaciones_parametros

Quiero que cada usuario pueda tener sus propios parámetros para una aplicación, y que cada aplicación tenga múltiples parámetros, donde manda un nombre de parámetro.

Quedaría:

usuarios:
-id

aplicaciones
-id

aplicaciones_parametros
-aplicaciones.id
-nombre_parametro

y que sería mejor para unir usuarios con parámetros de aplicaciones?

Esta solución:

usuarios_a_aplicaciones_parametros
- aplicaciones_parametros.aplicaciones_id
- aplicaciones_parametros.nombre_parametro
- valor

o esta otra solución:

- aplicaciones.id
- aplicaciones_parametros.nombre_parametro
- valor

No se que será mejor en cuanto a rendimiento.. y me da miedo que la aplicación al crecer se haga lenta, escucho cualquier planteamiento,

Un saludo!
__________________
Gracias por el Karma :D

empleo ofertas de trabajo
  #2 (permalink)  
Antiguo 08/02/2012, 06:34
Avatar de gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 7 meses
Puntos: 2658
Respuesta: Triple relación, dudas rendimiento y estructura

La primera solución es aplicable si y sólo si existen parámetros comunes entre diferentes aplicaciones y aplicaciones entre diferentes usuarios. Si cada parámetro de una aplicación es diferente para cada cada una de ellas, entonces ese modelo no es válido.
El segundo caso es precisamente el opuesto: Sólo sirve si no existen parámetros del mismo tipo en diferentes aplicaciones.
¿Se entiende?
__________________
¿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 08/02/2012, 13:58
 
Fecha de Ingreso: julio-2008
Ubicación: Barcelona
Mensajes: 2.100
Antigüedad: 16 años
Puntos: 165
Respuesta: Triple relación, dudas rendimiento y estructura

"La primera solución es aplicable si y sólo si existen parámetros comunes entre diferentes aplicaciones y aplicaciones entre diferentes usuarios"

Correcto, creo que me he dejado algo importante, los tres campos formarían una primary key, es decir, he planteado las dos soluciones para que cumplan con "existen parámetros comunes entre diferentes aplicaciones y aplicaciones entre diferentes usuarios"

Un saludo!
__________________
Gracias por el Karma :D

empleo ofertas de trabajo
  #4 (permalink)  
Antiguo 08/02/2012, 14:05
Avatar de gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 7 meses
Puntos: 2658
Respuesta: Triple relación, dudas rendimiento y estructura

Los ID, y sobre todo si son autoincrementales en su propia tabla, ya son valores únicos. No se deben usar para combinarse en la misma tabla con otros para formar claves primarias porque pierden su unicidad de PK.
Sí puedes usarlos dentro de otra tabla, como FK, pero en esa tabla sólo pueden ser al mismo tiempo PK si y sólo si esa tabla no posee una PK propia o bien si el campo discriminante no es un autoincremental. Si lo fuese pasaría lo mismo que en el otro caso: Se pierde la unicidad y puede haber inconsistencia de datos.
¿Se entiende la idea?
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)
  #5 (permalink)  
Antiguo 08/02/2012, 14:57
 
Fecha de Ingreso: julio-2008
Ubicación: Barcelona
Mensajes: 2.100
Antigüedad: 16 años
Puntos: 165
Respuesta: Triple relación, dudas rendimiento y estructura

Discúlpame, pero no lo entiendo,

Gracias por tu ayuda,

Un saludo!
__________________
Gracias por el Karma :D

empleo ofertas de trabajo
  #6 (permalink)  
Antiguo 08/02/2012, 16:20
Avatar de gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 7 meses
Puntos: 2658
Respuesta: Triple relación, dudas rendimiento y estructura

Es un tema que he tratado en diferentes posts muchas veces, referido a las PK y las tablas relacionales. Veamos si se puede simplificar:
- Es habitual que aquellos que recién se inician, los programadores y los que no tienen estudios formales supongan que una PK es siempre un campo numérico autoincremental. Eso no solo no es cierto, sino que es hasta desaconsejable usar autoincrementales como PK por diversas razones. Pero como es l a solución que probablemente uses, vamos a asumir que en cada tabla tu usas una PK numérica y autoincremental.
- Una PK creada de esa forma es siempre única, por definición de autoincremental: nunca se repite un número.
- SI usas un ID autoincremtnal, no puedes usarlo como parte de una PK compuesta porque como ese campo se incrementa en cada registro, y la PK es compuesta, basta incremento para permitir que los otros campos repitan valores, sin que se detecte la duplicidad.
Veamos el caso, de estos juegos de valores:
Cita:
(1, A, B, C, D, E)
(2, A, B, C, D, E)
(3, A, B, C, D, E)
(4, A, B, C, D, E)
(3, J, K, L, M, N)
Si hiciéramos que los tres primeros campos fuesen la clave, todos los registros podrían entrar sin ningún problema, a pesar de que los primeros tienen los datos repetidos desde el segundo campo.
¿Por qué?
Porque el primero campo cambia de valor en cada registro y la clave se evalúa como conjunto, y no por sus valores individuales.
¿Y el último registro? Está repitiendo el campo inicial...
Si, pero los otros dos campos no, y como la PK se evalúa en grupo, el error no se produce.

¿Se entiende hacia donde voy?
Cuando tienes una clave compuesta, el conjunto completo se evalúa y es el conjunto completo el que no debe repetirse. Si vas a usar una clave compuesta, procura que los campos de la tabla no incluyan ningún campo que sea autoincremental en esa misma tabla (si es una FK, que sea autoincremental en la tabla de origen no afecta).
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)
  #7 (permalink)  
Antiguo 09/02/2012, 02:24
 
Fecha de Ingreso: julio-2008
Ubicación: Barcelona
Mensajes: 2.100
Antigüedad: 16 años
Puntos: 165
Respuesta: Triple relación, dudas rendimiento y estructura

Hola buenas,

Muchas gracias por tu tiempo.

Entiendo perfectamente el tema de las primary keys auto incrementales, creo que más allá de la teoría, ai veces que creo que es muy recomendable que se use primary keys auto incrementales, ya que a mi no me parece óptimo en cuanto a rendimiento, poner una primary key del tipo varchar, que además ha de repetir en todas las relaciones de una base de datos, creo que se tiene que ser práctico y no estar tan reñido a "lo que esta bien y lo que esta mal", creo que en definitiva, la informática se tiene que adaptar a nosotros y no a la inversa. Dejando a un lado las opiniones personales, creo que no he dejado claro que la primary key de:

(1, A, B, C, D, E)
(2, A, B, C, D, E)
(3, A, B, C, D, E)
(4, A, B, C, D, E)
(3, J, K, L, M, N)

En mi caso, el primer campo viene de otra tabla y es una relación, por lo que cada uno de los tres primeros registros estaría correcto y sería totalmente distinto.

No se si me explico. EL primer campo haría referencia a una tabla cuyo campo primary key sería este, es decir, el primer campo es una relación, no un campo propio de esta tabla,

Un saludo!
__________________
Gracias por el Karma :D

empleo ofertas de trabajo

Etiquetas: dudas, estructura, rendimiento, tabla, triple
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 20:57.