Duda sobre diseño (campos de una tabla)

Soulscx

Hola, estoy intentando resolver un problema que parece sencillo, pero a la hora de plantear una solución no me gusta ninguna de las formas que he pensado, las veo poco eficientes, así que me gustaría saber algunas opiniones de los de aquí que pilotáis mazo.

El problema es que tengo que hacer un formulario al que se le pueden añadir preguntas personalizadas.
Cada una de esas preguntas tienen varias opciones, lo típico, nombre de pregunta, titulo,ayuda, etc... eso no tengo problema. La parte que no me gusta es que se puede elegir tipo de respuesta.
Por ejemplo:
-tipo texto
-fecha
-despleagable
-selección múltiple
-otros ...

A su vez si por ejemplo eliges texto tendra opciones:
-letras y numeros
-numeros
-letras
-telefonos
-pais
-comentarios
-etc ..

Entonces lo que se me habia ocurrido es que en la base de datos donde guardare toda esa informacion hacerme dos campos, por ejemplo:
-tipo_respuesta: integer
-tipo_texto:integer

Pero claro tambien necesitaré los campos para guardar la información:
-fecha:date
-texto:string
desplegable:integer
-etc ...

Es decir que si elijo la opcion texto, el campo fecha, desplegable, es decir, el resto de campos de las otras opciones disponibles quedan sin utilizar. No me gusta que queden tantos campos vacíos sin utilizar.

Había pensado en hacerme entidades distintas en plan pregunta_texto , pregunta_fecha, etc... y personalizarlo solo para ese tipo de respuesta. Pero no se si es bueno hacer tantas entidades.
Estoy trabajando con ruby on rails y sql. Tambien decir que soy aprendiz por lo que no me tireis muchas puyas.
La duda está orientada más en la parte de diseño y en los campos que necesito para representar y guardar esa información, con la mayor eficiencia posible. Puedo implementar mi solucion y añadirle miles de campos y listo, pero solo quería mejorar estas ideas. Gracias de antemano.

Merkury

Mientras los campos vacios esten en NULL, cero problemas.

El hacer entidades para el tipo de pregunta, tampoco es mala idea. Pero posiblemente sea mas rapido a la hora de hacer queries la primera opcion, aun teniendo campos en NULL

Soulscx

si, lo que no me mola es que en las especificaciones que me piden hay un montonazo de opciones que quieren dar y estoy imaginando que la cantidad de campos que voy a necesitar es muy basto y las que no usaran bastisimo :D

1 respuesta
NotToBit

#3 Ante un caso de herencia de clases tienes tres estrategias a seguir: TPH, TPT y TPC. No sé como funciona el mapeado de objetos en Rails, pero habitualmente los mapeadores soportan por lo menos dos de las opciones (Entity Framework por ejemplo no soporta completamente TPC, qeu de todas formas no se utiliza mucho). Me ha parecido que estás usando un mapeador de objetos/relacional, pero en caso de que no, los conceptos siguen siendo aplicables a nivel de creación de la base de datos.

TPH (Table per Hierarchy) es la que sugieres de tener una tabla para todas las preguntas posibles. Hasta donde llega mi conocimiento suele ser la más usada porque es la más rápida (generalmente con mucha diferencia). Su único inconveniente es que no puedes indicar si los campos de tipo son obligatorios o no a nivel de base de datos, pero puedes resolverlo tú por encima a código.
Yo personalmente utilizaría TPH salvo que estuviese trabajando con una base de datos que no soportase "sparce columns" (ni idea de como se dice en español), que es el caso en que esas celdas te comerían espacio a pesar de estar vacías.
Hay otras situaciones en las que puede convenir usar otra estrategia distinta, como si fueses a intentar montar un sistema en el que pudieses añadir nuevos tipos de preguntas en caliente, simplemente añadiendo su tabla de tipo correspondiente, pero eso ya depende del proyecto en particular.

EDIT: Te dejo ésta chuletilla de Entity Framework para que puedas mirar las diferentes opciones y decidir cuál te gusta más.

1
Soulscx

mirare a ver si las columnas null "no ocupan nada", si es asi entonces no me importa tener miles de campos null mientras no sobrecargue el sistema. Esto de hacer cosas dinámicas y guardarlas en bases de datos y con tanto nivel de anidamiento nunca había intentado algo así, gracias por los consejos!

Usuarios habituales

  • Soulscx
  • NotToBit
  • Merkury