Ni una ni otra. Estás planteando mal el modelo referencial. Lo que tienes es en realidad son las tablas (ejemplificando):
- Corredor(Corredor_id, nombre)
- Pista(pista_id, nombre, ubicacion, datos...)
- Carrera(carrera_id, nombre, fecha)
- Corredor_carrera(carrera_id, corredor_id, posicion_salida, posicion_final)
Este esquema te puede resolver la consulta de quienes participaron y en que posición llegaron en cada carrera y donde se hizo, cuando se hicieron , cuántas ganaron, y demás datos.
Tienes que recordar que:
1. Una FK es una clave referencial que relaciona un campo dado de una tabla con el campo clave (PK) de otra tabla. En ese sentido,
no existe tu modelo una tabla que contenga al mismo tiempo en la misma tabla todos los campos: `pos_1` , `pos_2` , `pos_3` , `pos_4` , `pos_5` , `pos_6` , `pos_7` , `pos_8` , `pole` , `rapida`. ¿O sí?
2. Un campo posicion1, posicion2, etc., en una tabla no tiene ningún sentido porque eso requeriría poner tantos campos como posiciones, o bien un conjunto de posiciones acotado, con lo que perderías la información de aquellos corredores que hayan salido fuera de esas posiciones (supongamos que guardas 16 y tienes 20 corredores, ¿qué pasó con los otros?). En cambio, una tabla que conserve las posiciones relacionadas con la carrera y con el conductor, requiere solamente esos campos para obtener todos los datos.
3. Además, poner tantos campos UNIQUE (ya que no puedes usar todos los campos como PK) lo único que haría es
reducir la performance por exceso de índices.
4. Un efecto adicional es que aún así, en el esquema que propones,
la misma carrera podría figurar en más de un registro, con sólo ingresar dos corredores con posiciones cambiadas. El sistema no lo notaria, porque poner 1,4,2,5 ó 1,2,4,5 como ID de conductores sería igualmente válido, porque el ordenamiento sería diferente. ¿Se comprende?, en cambio generar una PK con
carrera_id, corredor_id, posicion_salida, posicion_final no permitiría jamás una duplicación.
Un afinamiento del modelo podría incluir, por ejemplo, eventos ocurridos durante la carrera, lo que implicaría poner dos tablas adicionales:
- Corredor(Corredor_id, nombre)
- Pista(pista_id, nombre, ubicacion, datos...)
- Carrera(carrera_id, nombre, fecha)
- Corredor_carrera(carrera_id, corredor_id, posicion_salida, posicion_final)
- Corredor_carrera_evento(carrera_id, corredor_id, evento_id, evento_hora, otrosdatos...)
- Eventos(evento_id, evento_descripcion)
Este modelo podría codificar las ocurrencias y situaciones de la carrera, y solamente deberías almacenar lo que sucede según tiempo. Permitiría saber qué le ocurrió a un piloto durante cada carrera.
En definitiva, lo que tienes que profundizar es el análisis del sistema y crear un buen DER, antes de ponerte a implementar las tablas. Estos errores aparecen en el nivel de DER lógico con mucha facilidad.