¿Qué es lo mejor: 1 tabla por registro o 1 tabla con todos los registros vinculados con claves externas?

Question

Tengo una aplicación que permite a los usuarios crear diferentes formularios (encuestas) y luego llenarlos. (Así que es un sustituto del papel).

Aquí está el modelo actual que estoy usando en la aplicación:

Table 1) 
+-------------------------+ 
|  SURVEYS TABLE  | 
+----+------+-------------+ 
| ID | name | description | 
+----+------+-------------+ 

Table 2) 
+-----------------------------------+ 
|  $[name_of_the_survey]  | 
+----+-------+------+-------+-------+ 
| ID | field | type | value | items | 
+----+-------+------+-------+-------+ 


Table 3) 
+--------------------------------------+ 
| $[name_of_the_survey] _records | 
+----+---------------------------------+ 
| ID | columns specific to each survey | 
+----+---------------------------------+ 

así que básicamente cuando un usuario crea una encuesta, los programas inserta un registro en Servicios Tabla y luego crea 2 tablas:

tabla (2) para los campos del formulario tabla (3) para los registros que serán almacenes, en los cuales las columnas corresponden a la tabla (2) filas.

Funciona pero tiene algunas limitaciones. Por ejemplo, cuando desea agregar un campo a la tabla (2), debe leer los contenidos de la tabla (3), guardarlos en una tabla virtual, soltar la tabla anterior (3) y crear una nueva. Esto puede ser un problema de rendimiento cuando la tabla (3) tiene muchos registros.

Así que mi pregunta es ... ¿Hay un mejor diseño de base de datos?

Answer 1

El uso de una tabla separada para cada encuesta casi invalida el uso de una base de datos. También podría almacenar los resultados en archivos.

Sin embargo, necesita tres tablas: Definición de encuesta, Preguntas de encuesta y Respuestas de encuesta. Puede ser algo como esto ...

Surveys: 
ID; name; description 

Questions: 
ID; text; surveyID 

Answers: 
ID; answer; questionID 

Se podría añadir complejidad a partir de ahí para manejar respuestas enumeradas ...

Surveys: 
ID; name; description 

Questions: 
ID; text; surveyID 

Choices: 
ID; choice; questionID 

Answers: 
ID; choiceID 

utiliza la relación entre cada tabla a agregarse al siguiente nivel más alto , lo que le permite obtener resultados de cualquier pregunta, encuesta o cualquier otro atributo para cualquier modelo que elija agregar sin intentar abstraer la fuente de sus declaraciones seleccionadas. Esto también le permite agregar respuestas por usuario u organización encuestadora más adelante después de agregarlas a su esquema. Si cada encuesta tiene su propia estructura de tabla, la agregación de datos entre las encuestas se vuelve enormemente impráctica a medida que su aplicación crece.

Answer 2

Usted puede tratar de echar un vistazo a http://en.wikipedia.org/wiki/Database_normalization#Normal_forms

Lo anterior es bastante una manera formal de mejorar DBs en general, y algunos de los pasos que son relevantes para su base de datos. Creo que es un poco confuso con todos los campos de ID. ¿Realmente los necesitas para cada uno? ¿Los nombres de las encuestas no son únicos?

Ha implicado que los campos de datos de la encuesta son bastante únicos. Personalmente, clasificaría cada encuesta en un archivo y le daría un formato estándar. No es una mala idea si la tendencia es leer toda una encuesta a la vez. Solo usaría un DB si tuviera que ordenar o elegir y elegir fragmentos de datos.