Question

Hola a todos.

Estoy comenzando con un proyecto web de un CMS con sopoerte para varios idiomas en el frontend. Estoy empezando con el diseño de la base de datos y prácticamente la tengo toda diseñada excepto la parte relacionada con la sección Home o página principal del sitio.

El Home se va a gestionar en el backend en una sección específica para ello. Dentro del home habrá un slider con algunas imágenes, una sección donde aparecerán una serie de cursos seleccionados por el administrador y otras secciones similares a la anterior (profesores, lugares, etc. Las informaciones de cada una de estas secciones se encuentra cada una en su tabla correspondiente). El tema del slider lo tengo solucionado. El problema que tengo es cómo diseñar las tablas para guardar la información sobre las secciones de cursos, profesores, lugares, etc dentro del Home.

Tengo varias ideas en la cabeza, pero no sé cuál me conviene. Igualmente no me llegan a convencer del todo ninguna de ellas:

• Tener una tabla con una sola fila y las siguientes columnas: lista_cursos, lista_profesores, lista_lugares... En cada una de ellas guardaré una lista de identificadores, que apuntan a las claves primarias de sus tablas correspondientes.
• Tener una tabla por cada sección (una para profesores, otra para cursos...) y en cada fila introducir una clave ajena (clave foránea) que apunte al curso, profesor, lugar... respondiente. Se supone que la web no tendrá un tráfico excesivo, así que no creo que afecte mucho algún que otro "JOIN" de más, pero aún así este método no me convence del todo.
• En cada tabla correspondiente agregar un par de columnas: "home" y "orden_home". La primera será un booleano para indicar si ese curso, profesor... está seleccionado para aparecer en el Home y la segunda para poder ordenar esos elementos.

Como he dicho antes, en principio la web no tendrá un tráfico excesivo. ¿Cuál creéis que será mejor opción? ¿Alguna otra alternativa más óptima que se os ocurra?
Gracias de antemano, y buen día a todos :)

Answer 1

Hola @Joseda85,

hace tanto que no estoy en desacuerdo con el amigo @carlossevi que se siente raro dar una respuesta diferente...

La Normalización no es una cuestión de opiniones, es cuestión de aplicar la norma. Lo que sí es opinable es la forma de salirse de la norma, para lo que hay que evaluar muy bien pros y contras en el contexto del proyecto. La parte más contraintuitiva de esto es que, aplicando la Normlaización, el esquema de almacenamiento suele verse más grande y pesado, sin embargo, los RDBMS están optimizados para justamente ser eficientes en almacenamientos normalizados, y se comportan bastante mal en situaciones diferentes.

En tu caso la normalización dice qeu tenés que agregar 3 tablas más para resolver este problema:

Curso_Seccion
--------------
id
id_curso
id_seccion
orden

Profesor_Seccion
--------------
id
id_profesor
id_seccion
orden

Lugar_Seccion
--------------
id
id_lugar
id_seccion
orden

De esta forma incluso queda generalizado para cualquier sección, si bien en el id_seccion siempre será el de la home.

Answer 2

La primera opción la descartaría ya que rompe con una estructura normalizada de la base de datos.

Respecto a las diferencias de las soluciones 2 y 3, en función de cómo tengas creados los índices de las tablas, puede ser que para tu sorpresa la segunta tenga mejor rendimiento que la tercera puesto que entiendo que la tabla del home tendrá muy pocos registros y a las tablas "gordas" acudirás a buscar en el JOIN mediante una clave primaria (muy eficiente).

La tercera opción es buena formalmente, puede no tener impacto sobre el rendimiento si generas los índices adecuados a la tabla sobre las columnas home y orden_home y además te implicaría muy pocos cambios en tu desarrollo. A mi me gusta.

Una cuarta opción, que para mí sustituiría a la 2, es una tabla similar a la siguiente:

CREATE  TABLE `home` (
  `id` INT NOT NULL AUTO_INCREMENT ,
  `orden` INT NOT NULL,
  `tipo_registro` ENUM('profesores','cursos') NOT NULL ,
  `id_profesor` INT NULL ,
  `id_curso` INT NULL ,
  PRIMARY KEY (`id`) ),
  UNIQUE INDEX `orden_UNIQUE` (`orden` ASC) );

Cada columna id_xxx podrá ser nula y además será clave foránea de la tabla relacionada, y en función de cada tipo de registro se espera recoger el valor de una columna u otra.