eficiencia en claves primarias

[ivan_teruel92]

que es mas eficiente en una tabla en la que el numero necesario de claves primarias es alto, ¿¿ crear una nueva columna de tipo autoincrement (por ejemplo) como clave primaria, o dejar todas las columnas existentes como indice y olvidarnos de crear una nueva??

imaginaros que en cierta tabla necesitamos 4 o 5 columnas para crear una tabla primaria... ¿que creeis que seria mas eficiente?

[gnzsoloyo]

Habría que analizar el caso, y es posible que exista cierta falla en la normalización de la tabla, porque una PK que contenga demasiados campos puede implicar eso: una normalización o un modelado incorrectos.
En términos generales, hay que evitar las autoincrementales, porque traen a la larga problemas de consolidación, de migración y algunos otros más. Son una solución de fórceps propia de programadores, y sólo se deberían usar si al llegar a la 3FN no has hallado una CC, que no es tu caso.
¿Podrías mostrarnos tu diseño de tablas como para ver qué es lo que realmente conviene hacer?

[ivan_teruel92]

la verdad que es demasiado complicado mostrarte el diseño de tablas porque abria como 40 :S y si no conoces el sistema es dificil de enteder en un post, de todas formas te agradezco tu aportacion.

Graicias.

[gnzsoloyo]

No es necesario que muestres todas. Podrías mostrar algunos casos típicos y detallar qué relación representan...

[ivan_teruel92]

lo decia por casos en los que tenogo 5 o 6 claves primarias, a esos casos me refiero... no me imagino mandando una peticion get para obtener el valor de un campo teniendo que pasar 6 parametros, el nombre de un usuario, una fecha, una provincia.... lo veo una locura

por ejemplo

un usuario crea un "trabajo" que puede trabajar en distintas provincias, a esas provincias se asignan ofertas que dependen de otra tabla "fechas" en la que se guardan que fechas tiene libre un usuario (el anterior)

a "ofertas" me llegan el identificador del usuario, + el del "trabajo" + el de la "provincia" + el de la "fecha"... ahora imaginate que a esa oferta le asignamos yo que se... una foto...

[gnzsoloyo]

¿Y tienes toda esa estructura en una sola tabla?
Lo que describes es una estructura de varias tablas relacionadas, y lo que llamas "5 o 6 claves primarias", es en realidad el resultado de un JOIN entre tablas, no una llave primaria. En ese caso, la búsqueda de un dato determinado requiere de esos parámetros para localizar uno en particular, no una PK multicampo, pero nada más.

[ivan_teruel92]

Estas en lo cierto que me refiero a una estructura de tablas... oferta seria una tabla, "fechas" seria otra tabla, usuario seria otra tabla, trabajo otra...

el problema surje que al crear el modelo relacional tengo que ir transmitiendo de una tabla a otra sus claves primarias, siendo estas parte de la siguiente no se si me explico...

la clave primaria de "trabajo" sera la clave primaria de "usuario" mas un identificador de trabajo como puede ser "nombre", la clave primaria de "provincias" sera la clave primaria de "trabajo" mas la clave primaria de "usuario" mas otro identificador.... debido a la relacion entre las tablas.. no tengo forma de crear una clave primaria de "Provincias" si no puedo distinguir de que usuario y a que trabajo pertenece....


serian claves primareas y foraneas al mismo tiempo por la relacion de identificacion

(uso inodb para crear las relaciones)

[gnzsoloyo]

Creo que estás creando relaciones transitivas entre las tablas, y ese es un error conceptual.
Supongamos un esquema como el que describes, que se parece a una "bolsa de trabajo", como se denominaban en mi provincia:

un usuario crea un "trabajo" que puede trabajar (realizarse) en distintas provincias, a esas provincias se asignan ofertas que dependen de otra tabla "fechas" en la que se guardan que fechas tiene libre un usuario (el anterior)

Voy a hacerte una salvedad: No tiene sentido guardar "fechas libres" que tiene un usuario. Eso implicaría crear registros vacíos para la tabla en la base, lo que redunda en ineficiencia de consultas. Los días libres se obtienen al procesar los datos de los días usados, y se debe hacer por programación, no en la base.
El esquema que planteas se podría representar más o menos así:



En este esquema, un usuario puede crear un tipo de trabajo, o usar alguno ya definido (la tabla podría ser fija). A su vez de ese trabajo puede crear una oferta, para una fecha o período determinado, que debe estar en alguna provincia (tabla fija).
por otro lado, un usuario podría aceptar una oferta ya hecha.
En este esquema se puede consultar perfectamente:
- Qué ofertas hay, para qué fechas y en dónde.
- Quienes han hecho esas ofertas, (agregando datos) cuando y para qué período.
- Quienes pueden hacer realizado trabajos similares.
- Qué disponibilidad de tiempo tienen para esos trabajos.
- Qué períodos han trabajado, haciendo qué y dónde

Pero por sobre todo, puedes notar que el esquema de PK que tiene es simple. No existe transitividad ni transferencia de PKs, porque en realidad ese tipo de relaciones no las necesita como PK. Las requiere como FK.
Algunas restricciones, como evitar que el mismo usuario ingrese el mismo trabajo, o que se dupliquen las ofertas, se resuelve creando índices UNIQUE y no necesariamente haciendo PKs innecesariamente complicadas.

Al menos esta en mi visión a vuelo de pájaro, par aun problema así. No sé si me estoy aproximando a la idea del sistema que tienes que implementar.

[ivan_teruel92]

vale, nos vamos entendiendo. me sirvio mucho tu ejemplo solo un par de dudas/apuntes

he mejorado mi estructura pero no dejo de fijarme en los siguientes campos :

cod_trabajo, idOferta, idProvincia

estos son los campos a los que me referia al decir "crear una nueva columna de tipo autoincrement (por ejemplo) como clave primaria" ya quee son campos que no existen en la realidad, es decir, una provincia no tiene un identificador "real" sino que es algo ficticio que se le asigna para poder "Identificarlo", por ejemplo, haciendo un autoincrement o poniendolo tu "a mano"

la forma en la que lo habia planteado yo es no teniendo que crear ningun campo el cual "no exista en la realidad", es decir, si de la provincia tengo que guardar el nombre de la provincia, no crear un campo "idProvincia" ficticio.... de esta forma en algunas tablas tengo que cojer mas de un campo para poder crear una clave primaria efectiva... a esto me referia al preguntar si es eficiente, si merece la pena crear un campo "ficticio de id" o utilizar los existentes para encontrar convinaciones efectivas para crear una clave primaria....

de todas formas estudiare mejor tu caso y las posibilidades de incluir campos tipo unique...

muchas gracias la verdad que da gusto encontrarse a gente como tu.. que seria de nosotros los autodidactas y menos con mi edad.... jejej sino jejejjeje gracias de corazón

PD: ¿que programa utilizaste para hacer el esquema?

[gnzsoloyo]

estos son los campos a los que me referia al decir "crear una nueva columna de tipo autoincrement (por ejemplo) como clave primaria" ya quee son campos que no existen en la realidad, es decir, una provincia no tiene un identificador "real" sino que es algo ficticio que se le asigna para poder "Identificarlo", por ejemplo, haciendo un autoincrement o poniéndolo tu "a mano"

Bueno, en realidad, si te fijas con cuidado, yo no he puesto esos ID como autoincrementales. Ni siquiera como INT, sino como varchar, porque estoy suponiendo que en el caso de los trabajos se trata de un sistema de codificación definido para el sistema basado en códigos alfanuméricos, o bien en códigos establecidos por algún sistema ya establecido, por ejemplo el usado por el fisco en cada país.
En el caso de las provincias, tampoco estoy usando un sistema hecho a mano o de autoincrementales, sino que tomo un VARCHAR(8), suponiendo que se use, por ejemplo, el CPA argentino, es decir, el sistema de codificación postal, que no sólo me indica la provincia, sino incluso la ciudad, y la ubicación en la manzana y hasta el lado de la calle del sitio. El del usuario es el numero de documento (bien puede ser el username).
Sólo uso numéricos para el ID de la oferta, pero el mismo se puede cambiar por otro.
El modelo en si no requiere de autoincrementales. Solamente requiere que definas un sistema de identificación para la tabla. En ese caso, incluso, en la aplicación el usuario podría elegir un oficio o trabajo de un combo de posibilidades prefijadas, por lo que seleccionaría el nombre, pero lo que quedaría almacenado sería el código. Eso se resuelve, como digo, en la aplicación y es invisible para los usuarios.

¿Se comprende la idea?

[ivan_teruel92]

Entendido muchas gracias ;)

Solo una cosa mas... un poco fuera del tema

¿podrias explicarme un poco mas el tema de los problemas relacionados con los autoincrementales? no me habia panteado eso.. supongo que soy mas "programador" jjajajaja y llevo mucho tiempo usandolos...

[gnzsoloyo]

Si. los autoincrementales son fáciles, y cuando te enseñan programación te los dan como si fueran algo natural. No es así.
Un ID autoincremental es una forma fácil de resolver las PK, pero sólo si trabajas con una única base, un sólo servidor y un mismo sistema completamente integrado.
Pero cuando tienes, por ejemplo:
- Varias bases que tengan tablas en común por su diseño, pero funcionen separadamente.
- Más de una "sucursal" con su propia base, la que debe consolidarse (concentrar los datos en una sola central cada tanto tiempo).
- Procesos de borrado y reinicio de bases por razones procedimentales o de seguridad.
- Datawarehouses o Datamarts.
- Procesos de integración de bases distintas con estructuras conceptuales coincidentes (clases o tablas).
- otros casos.En todas estas situaciones puedes encontrarte con solapamientos de claves (en la integración y recuperaciones de datos), o bien duplicaciones parciales de registros por claves no coincidentes (claves distintas con datos iguales).

Todo eso hace que cuando debas migrar o integrar tablas de diferentes orígenes, tengas que planear procesos que compensen esas discrepancias. Y todo proceso implica adicional ineficiencia y tiempo perdido.

Se supone, según los expertos en el tema de normalización de BBDD, que un indice numérico (autoincremental o no) sólo debe usarse si y sólo si llegados a la 3FN no has encontrado una clave candidata. Para el caso, existe una forma de evitar inconsistencias de integración entre diferentes bases y es haciendo que el step (valor de incremento) de un AI sea mayor a 1, siendo normalmente equivalente a la cantidad de bases distribuidas que se usen (3 bases, step de 3). En ese caso, al integrarlas, los registros quedan intercalados numéricamente sin conflictos. Pero tienen dos problemas: 1) No evita las duplicaciones de datos, solo los solapamientos, 2) no permite hacer listados directos sin verificar el valor de múltiplo de la PK.

Además de eso, una PK crea un índice cluster, el que se utiliza para mantener el orden físico de los registros, pero como es incremental , el orden es el de entrada, que puede no ser el orden más usado en las consultas, lo que obliga a crear indices específicos, que el sistema debe mantener actualizados según los datos que ingresen o se modifiquen. Si tienes en cuenta que muchas veces esos ordenes también implican hacer indices de tipo UNIQUE, el uso de la PK autoincremental deja de tener sentido, porque un indice de ese tipo implica que existe al menos una CC (clave candidata), y en ese caso ¿para qué usar una AI?
A nivel de consultas, debes tener en cuenta también que si la PK definida sobre los campos de la tabla contiene también los campos usados en la mayoría de las consultas, estas serán siempre más eficientes que usar un AI. Incluso más: Aquellas consultas que impliquen sólo los campos que aparecen en el índice son mucho más rápidas, porque en ese caso MySQL lee el índice pero no lee la tabla.

El tema central es que una PK creada ortodoxamente en base a la definición del modelo relacional es siempre la mejor de las opciones, por más complicaciones que te pueda traer en la programación. La ventaja que tienen para las migraciones es que como se definen sobre datos reales de la entidad representada, por más que haya repeticiones (manejables) en la integración, sabrás que no hay inconsistencias en los datos, y necesitarás procesos muchísimo más simples. A veces son simples

Código MySQL:

INSERT IGNORE INTO ....
SELECT * FROM TABLA;
 

¿Se entiende por dónde va la cosa?

[ivan_teruel92]

osea que casi seria preferible, en caso de que sea necesario, crear un clave unica mediante un proceso (un algoritmo) que hacer un autoincrement??

Muchisimas gracias, la verdad en cada mensaje me sorprendo mas da gusto encontrarse con gente como tu

[gnzsoloyo]

No se usan procesos para las PK. Se debe analizar la entidad que se está representando y ajustarse al paradigma.
La definición es simple: "Es un campo o conjunto de campos que identifica unívocamente un registro en una tabla". No dice qué tipos de campo. Lo que debes hacer es observar los atributos de la entidad y definir cuál o cuáles de ellos en grupo permitiría identificar ese registro en el sistema.
A veces es el documento (personas), en otras ocasiones en el numero de factura y el del ítem (detalles de facturas), en otras es un código universal (teléfonos, números de serie, MACs, números de código de barras, ISBN, etc.), en otras una secuencia irrepetible (IP+username). Hay muchas formas. Lo que tiene que hacer es cumplir la definición.
La idea central es que debe ser algo propio de la entidad y no algo que se agrega.
En forma extendida, se lo define como un determinante, tal que todos los atributos de la entidad dependan de ese valor o valores combinados. Luego de esa definición hay algunos otros conceptos que permiten crear bases mejor diseñadas (Formas Normales).

[ivan_teruel92]

por ejemplo tengo un tabla que almacena comentarios con los siguientes datos:

fecha, puntuacion, usuario, texto, + una clave foranea (identificador del anuncio)

el problema es que puede haber un comentario del mismo usuario en la misma fecha con la misma puntuacion en el mismo anuncio....

en este caso o hago un autoincrement o creo yo un indice :S no?

[gnzsoloyo]

Puede ser en la misma fecha, pero no en la misma fecha y hora...
Allí la PK podría ser fecha+username, porque es imposible, y en todo caso no se debe permitir, que un usuario pueda enviar dos mensajes al mismo tiempo. Ni siquiera si estuviese logueado en dos PCs al mismo tiempo.
Así, la PK sería usuario+fecha_hora, el anuncio_id, sería FK y el resto atributos de esa entidad (texto y puntaje).