Mas tablas es mejor?

[NUCKLEAR]

Hola compañeros, les comento:
Normalmente las relaciones entre tablas(one-to-one, many-to-many) las manejo relacionandolas con un campo _id dentro de la otra tabla - vamos como se hace tradicionalmente -

table:
Alumnos : id, nombre, apellido, cursos_id

table:
cursos : id, nombrecurso

Pero estuve leyendo un poco y veo que hay una controversia en jacer uso de este sistema, muchos recomiendan hacer la relación con una tercera tabla

alumnos_cursos
id, cursos, alumnos

Mi pregunta es como lo hacen ustedes, he inbagado pero siempre encuentro puntos medios. El ejemplo que puse es algo mínimo normalmente trabajo con mas tablas relacionadas.

Saludos,

[gnzsoloyo]

En realidad no existe controversia al respecto. Si profundizas en el estudio de bases de datos relacionales encontrarás las respuestas fácilmente.

1. En las relaciones 1:1, se pone una PK de una tabla en la otra tabla. Es indistinto qué clave se pone en cuál, pero para hacerlo de una forma consistente hay que analizar las entidades que estás relacionando. Por decirlo así, si tuvieses una tabla CUERPO_HUMANO y otra MIEMBRO_CUERPO, la FK de CUERPO_HUMANO va en MIEMBRO_CUERPO porque el miembro le pertenece a un cuerpo, y no el cuerpo a un miembro... ¿Se entiende la idea? la FK va en la tabla lógicamente dependiente de la otra.

2. Las relaciones 1:N son más simples. La FK va siempre en la entidad de cardinalidad N, ya que es la expresión de su dependencia formal, y no sólo una dependencia conceptual.

3. Las relaciones N:N siempre se expresan con una tabla nueva que representa la relación y en donde las FK son la clave primaria o forman parte de ella. No hay otra opción, porque para que pusieses simplemente una PK en la FK de la otra tabla vinculada como en el anterior caso, siendo que ambas son de cardinalidad N deberías poner muchos registros repetidos donde sólo cambiase el valor de la FK, pero los otros datos fuesen iguales.... y eso generaría un enorme problema de consistencia, normalización, etc.

[NUCKLEAR]

Gracias gnzsoloyo voy entendiendo, pero en caso de no poder usar una bd que no soporte FK, como se hacia anteriormnte? La relación FK unicamente sigue de "Guia" o tiene algun impacto en las consultas?

Es que hay tanta información y como te digo hay mucha ambiguedad en las respuestas.
El caso de Wordpress por ejemplo tas relaciónes las hacen directamente con campos relacionados y se puede usar Myisam y funciona a las mil maravillas.
Drupal es un caso aparte, usa terceras tablas para la mayoria de relaciones. La consulta a un nodo te puede tomar tres tablas. y funciona tambien con Myisam a las mil maravillas.

Por eso mi duda, como lo hacen/harian ustedes. suponiendo el ejemplo que expuse N:N

[gnzsoloyo]

Gracias gnzsoloyo voy entendiendo, pero en caso de no poder usar una bd que no soporte FK, como se hacia anteriormnte? La relación FK unicamente sigue de "Guia" o tiene algun impacto en las consultas?

Bueno, la única forma era mantener la consistencia programáticamente. En esencia se sigue haciendo en MySQL cuando usas tablas MyISAM, que no soportan restricciones de FK. Las tablas de tipo MyISAM se usan cuando lo que te importa es la rapidez y no la consistencia, y además no te importa tener que programar mucho más para asegurar la validez, o tener que crear transacciones programáticamente también. Pero nadie apostaría a un sistema contable basado en MyISAM, por ejemplo.

En realidad, el uso de las restricciones de FK, entre otras cosas, ayudan a mantener la consistencia e integridad de los datos, ya que cuando se las establece no hay forma de ingresar datos que no cumplan con las reglas impuestas a la base. Ese es uno de sus sentidos; su uso en las consultas es una consecuencia de esa restricción.
El hecho de implementar las relaciones de FK exige un incremento de secuencialidad de inserciones, y el uso de transacciones, pero luego se gana en precisión y en la eficiencia de las consultas.

Los sistemas de bases de datos que no soportan restricciones de FK pueden simularla, como es el caso de Wordpress y Drupal, pero como te dije, eso implica un aumento de la programación precisamente para solventar lo que las InnoDB tienen por definición manejado en la base.