Una pregunta para principiantes sobre diseño de base de datos

Question

esta es una pregunta de seguimiento sobre mi anterior. Los estudiantes de tercer año estamos haciendo un desarrollo de sitio web para la universidad como trabajo voluntario. Estamos utilizando la técnica PHP + MySQL. Ahora soy el principal responsable del desarrollo de la base de datos usando MySQL, pero soy un diseñador de MySQL. Ahora estoy pidiendo algunas pistas sobre cómo escribir mi primera tabla, ponerla en mis manos y luego trabajar con otras tablas. La pregunta es la siguiente, lo primero que hará nuestro sitio web es presentar una encuesta al usuario para recabar su preferencia sobre cuándo quiere usar el servicio de autobús. y aquí es donde voy a comenzar el desarrollo de mi base de datos. El documento de requerimientos del usuario especifica que para la encuesta, no debería haber

lado del cliente:

Encuesta de estará disponible para los clientes, con un juego de preguntas y respuestas predefinidas y debe ser fácil de llenar

Lado del negocio:

Información de seguridad. será almacenado, superado y visualizable para su análisis.

No suena demasiado trabajo, y no necesito preocuparme por nada de PHP, pero estoy confundido sobre: ​​¿debería crear una sola tabla llamada "Survery", o dos tablas "Survey_business" y "Survey_Customer" ", y ¿cómo puede la base de datos almacenar la información? Les agradecería que me ayudaran para que yo pueda trabajar, porque el primer paso es siempre el más difícil y el más importante. Gracias.

Answer 1

Usaría varias tablas. Uno para las encuestas en sí, y otro para las preguntas. Tal vez uno más para las opciones de respuesta, si quieres ir con preguntas de opción múltiple. Otra tabla para las respuestas con un registro por pregunta por contestador. La complejidad aumenta a medida que considera múltiples tipos de respuestas (opción, completar una línea en blanco, línea múltiple de forma libre, etc.) y opciones de visualización (botón de opción, lista desplegable, cuadro de texto, yada yada), pero para un simple ejemplo de opción múltiple con un solo tipo de representación, esto funcionaría, creo.

Algo así como:

-- Survey info such as title, publish dates, etc. 
create table Surveys 
(
    survey_id number, 
    survey_title varchar2(200) 
) 

-- one record per question, associated with the parent survey 
create table Questions 
(
    question_id number, 
    survey_id number, 
    question varchar2(200) 
) 

-- one record per multiple-choice option in a question 
create table Choices 
(
    choice_id number, 
    question_id number, 
    choice varchar2(200) 
) 

-- one record per question per answerer to keep track of who 
-- answered each question 
create table Answers 
(
    answer_id number, 
    answerer_id number, 
    choice_id number 
) 

A continuación, utilice el código de aplicación a:

1. insertar nuevas encuestas y preguntas.
2. Rellenar respuestas a medida que las personas toman las encuestas.
3. Informe sobre los resultados después de que la encuesta esté en progreso.

Usted, como desarrollador de la base de datos, podría trabajar con el desarrollador de la aplicación web para diseñar las consultas que se llenarían y recuperar los datos apropiados para cada tarea.

Answer 2

única tabla 1, que va a cambiar sólo el modo de usar la tabla para cada dato de inserción OCASION

clientes lateral en la tabla

lado del negocio leer los datos y resultados de la misma tabla

Answer 3

Survey.Customer suena como una función de almacenamiento, mientras que Survey.Business suena como una función de recuperación.

Las únicas tablas que necesita son para el almacenamiento. Las operaciones de recuperación se llevarán a cabo mediante consultas e informes de las tablas de almacenamiento existentes, por lo que no necesita tablas adicionales para esas.

Answer 4

Utilice una sola tabla solamente. Si tuviera que usar dos tablas, cada vez que realice un cambio, tendría que hacerlo todo dos veces. Eso es un gran problema para el mantenimiento para usted y cualquier otra persona que venga a hacerlo en el futuro.

Answer 5

mayoría de los consejos/respuestas hasta el momento son aplicables pero asegúrese (no declarado!) Suposiciones acerca de su dominio

tratar de hacer un modelo lógico de las entidades y atributos que se requieren para capturar los requisitos, examinar la relaciones, considere cómo se usarán los datos en ambos lados del proceso y luego diseñe las tablas. Hable con los usuarios, hable con las personas que ejecutarán los informes, hable con quien diseñe la interfaz de usuario (pantallas e informes) para obtener una imagen completa.

prestar mucha atención al los requisitos de información, ya que a menudo implican atributos y entidades no existentes en el esquema de entrada de datos

Answer 6

son los datos que usted está presentando como las preguntas y respuestas que van a ser dinámico? ¿Es este un proyecto a largo plazo que tendrá preguntas intercambiadas? Si es así, probablemente también quiera tener las preguntas y respuestas en su base de datos.

La forma en que lo haría sería definir sus entidades y descubrir cómo diseñar sus tablas para que las relaciones sean sencillas. Me suena como que tiene tres entidades:

• Pregunta
• respuesta
• completará el reconocimiento

Answer 7

Sólo una elaboración muestra de lo que Steven y Chris se ha mencionado anteriormente.

Habrá varias tablas, si va a haber varias encuestas, y cada encuesta tiene un conjunto diferente de preguntas, y si el mismo usuario puede tomar múltiples encuestas.

1. Tabla cliente con CustID como la clave principal

2. Preguntas tabla con un ID de preguntas como la clave principal. Si una pregunta no puede pertenecer a más de una encuesta (una relación N: 1), también puede tener ID de encuesta (de la tabla Tabla de encuestas mencionada en el punto 3) como uno de los valores en la tabla.

3. Pero si una encuesta a la pregunta relación es N: M, entonces (SurveryID, IdPregunta) se convertiría en una clave compuesta para la SurveyTable, de lo contrario sólo tendría la SurveyID con los detalles de alto nivel de la encuesta como la descripción .

4. mesa UserSurvey que contendría (identificador de usuario, SurveryID, IdPregunta, AnswerGiven)

   [Nota: si mismo usuario puede tener la misma encuesta y otra vez, ya sea el antiguo encuesta tiene que ser actualizado o los intentos de repetición han de almacenarse como otras filas con un número de serie)

Answer 8

Creo 2 mesas necesarios:

• una mesa encuesta para almacenar las preguntas y opciones para una nswer. cada encuesta se almacenará en una fila con una identificación de encuesta única
• otra tabla es para almacenar respuestas. Creo que es mejor almacenar la respuesta de cada cliente en una fila con una identificación de encuesta y una identificación de cliente si es necesario.

luego puede calcular los resultados y almacenarlos en una vista de resultados de encuesta.