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

Tengo una aplicación que permite a los usuarios crear diferentes formularios (encuestas) y luego rellenarlos. (Por lo que es un sustituto para el 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 | +----+---------------------------------+

Por lo que básicamente cuando un usuario crea una encuesta, los programas inserta un registro en la tabla de encuestas y luego crea 2 tablas:

Tabla (2) para los campos de la tabla de formularios (3) para los registros que serán almacenes, en los que las columnas corresponden a filas de la tabla (2).

Funciona pero tiene algunas limitaciones. Por ejemplo, cuando usted agrega un campo a la tabla (2), tiene que leer el contenido de la tabla (3), guardarlo en una tabla virtual, eliminar 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?

El uso de una tabla separada para cada encuesta casi invalida el uso de una base de datos. Es mejor que sólo almacene los resultados en archivos.

Sin embargo, necesita tres tablas: Definición de la encuesta, Preguntas de la encuesta y Respuestas de la encuesta. Puede parecer algo así …

 Surveys: ID; name; description Questions: ID; text; surveyID Answers: ID; answer; questionID

Podría agregar complejidad desde allí para manejar respuestas enumeradas …

 Surveys: ID; name; description Questions: ID; text; surveyID Choices: ID; choice; questionID Answers: ID; choiceID

Utiliza las relaciones entre cada tabla para agregar al siguiente nivel más alto, lo que te permite obtener resultados de cualquier pregunta, encuesta o cualquier otro atributo para cualquier modelo que elijas agregar sin tratar de abstraer el origen de tus declaraciones selectas. Esto también le permite agregar respuestas por usuario o agrimensura de la organización más adelante después de agregarlas a su esquema. Si cada encuesta tiene su propia estructura de tabla, la agregación de datos a través de encuestas se vuelve enormemente impracticable a medida que su aplicación crece.

Puede intentar echar un vistazo a http://en.wikipedia.org/wiki/Database_normalization#Normal_forms

Lo anterior es una manera bastante formal de mejorar los DB en general, y algunos de los pasos son relevantes para tu DB. 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?

Usted ha implicado que los campos de datos de la encuesta son absolutamente únicos. Personalmente me gustaría poner cada encuesta en un archivo, y simplemente darle un formato estándar. No es una mala idea si la tendencia es leer una encuesta completa a la vez. Yo sólo usaría un DB si tuviera que ordenar o seleccionar y elegir bits de datos.