Una domanda per principianti sulla progettazione del database

Question

questa è una domanda successiva sulla mia precedente. Gli studenti del secondo anno stanno facendo lo sviluppo di siti web per l'università come volontariato. Stiamo usando la tecnica PHP + MySQL. Ora sono principalmente responsabile dello sviluppo del database usando MySQL, ma sono un designer MySQL. Ora sto chiedendo alcuni suggerimenti per scrivere il mio primo tavolo, per metterlo tra le mani, quindi potrei lavorare bene con altri tavoli. Il quesiton è come questo, la prima cosa che il nostro sito Web sta per fare è presentare un sondaggio all'utente per raccogliere le proprie preferenze su quando vogliono usare il servizio di autobus. e questo è dove ho intenzione di iniziare lo sviluppo del mio database. Il Documento Requisiti Utente specifica che per l'indagine, ci dovrebbe essere

Lato cliente:

indagine in sarà a disposizione dei clienti, con una serie di domande e risposte predefinite e dovrebbe essere facile da compilare

Business:

Informazioni survery. saranno archiviati, stampati e visualizzabili per l'analisi.

Esso non sembrare troppo lavoro, e non ho bisogno di prendersi cura di qualsiasi cosa PHP, ma sono solo confuso su: Devo solo creat una singola tabella denominata "indagine in", o due tavoli "Survey_business" e "Survey_Customer "e in che modo il database può memorizzare le informazioni? Sarei grato se voi ragazzi poteste darmi un aiuto in modo che possa lavorare insieme, perché il primo passo è sempre il più difficile e più importante. Grazie.

Answer 1

Vorrei utilizzare più tabelle. Uno per gli stessi sondaggi e un altro per le domande. Forse un altro per le opzioni di risposta, se si vuole andare con domande a scelta multipla. Un'altra tabella per le risposte con un record per domanda per rispondente. La complessità si intensifica quando si considerano più tipi di risposte (scelta, single-line vuota, multiline in formato libero, ecc.) E opzioni di visualizzazione (pulsante di scelta, elenco a discesa, casella di testo, yada yada), ma per un semplice esempio a scelta multipla con un singolo tipo di rendering, questo funzionerebbe, penso.

Qualcosa di simile:

-- 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 
) 

Quindi utilizzare codice dell'applicazione per:

1. Inserire nuovi sondaggi e domande.
2. Compila le risposte mentre le persone eseguono i sondaggi.
3. Rapporto sui risultati dopo che il sondaggio è in corso.

Tu, come sviluppatore del database, potresti lavorare con lo sviluppatore di app Web per progettare le query che popolerebbero e recupererebbero i dati appropriati per ogni attività.

Answer 2

solo 1 tavolo, cambierai solo il modo di usare la tabella per ogni inserimento di dati ocasion

clienti lato nella tabella

commercio laterale leggere i dati e risultati dalla stessa tabella

Answer 3

Sondaggio. Il cliente sembra una funzione di archiviazione, mentre Survey.Business sembra una funzione di recupero.

Gli unici tavoli necessari sono per la conservazione. Le operazioni di recupero avverranno utilizzando query e report delle tabelle di archiviazione esistenti, quindi non sono necessarie tabelle aggiuntive per tali.

Answer 4

Utilizzare solo una tabella. Se dovessi usare due tabelle, ogni volta che apporti una modifica, dovresti fare tutto il doppio. Questo è un grosso problema per la manutenzione per te e per chiunque altro entri a farlo in futuro.

Answer 5

maggior parte dei consigli/risposte sono finora applicabile, ma rendere certo (non dichiarata!) Ipotesi sul tuo dominio

provare a fare un modello logico delle entità e gli attributi necessari per catturare i requisiti, esaminare il relazioni, considerare come i dati verranno utilizzati su entrambi i lati del processo e quindi progettare le tabelle. Parla con gli utenti, parla con le persone che gestiranno i report, parla con chiunque stia progettando l'interfaccia utente (schermi e report) per ottenere il quadro completo.

prestare molta attenzione agli obblighi di comunicazione, in quanto spesso implicano attributi ed entità non esistenti nello schema di immissione dati

Answer 6

sono i dati che stai presentando le domande e le risposte che vanno ad essere dinamico? Si tratta di un progetto a lungo termine che avrà delle domande da scambiare? Se è così, probabilmente vorrai avere le domande e le risposte anche nel tuo database.

Il modo in cui farei sarebbe definire le entità e capire come progettare le tabelle in modo che le relazioni siano semplici. Mi sembra di avere tre entità:

• Domanda
• risposta
• Completato Survey

Answer 7

Basta un'elaborazione esempio di ciò che Steven e Chris si è accennato in precedenza.

Ci saranno più tabelle, se ci saranno più sondaggi, e ogni sondaggio ha una serie diversa di domande e se lo stesso utente può effettuare più sondaggi.

1. Customer Table con CustID come chiave primaria

2. Domande da tavolo con un ID di domanda come chiave primaria. Se una domanda non può appartenere a più di un sondaggio (una relazione N: 1), allora può anche avere ID sondaggio (della tabella Survey tabella di cui al punto 3) come uno dei valori nella tabella.

3. Ma se un sondaggio della questione sub rapporto è N: M, quindi (SurveryID, QuestionID) sarebbe diventato una chiave composta per il SurveyTable, altrimenti sarebbe solo avere il SurveyID con i dettagli di alto livello del sondaggio come descrizione .

4. tavolo UserSurvey che conterrebbe (userID, SurveryID, QuestionID, AnswerGiven)

   [Nota: se stesso utente può prendere più e più volte la stessa indagine, o il vecchio sondaggio deve essere aggiornata o tentativi di ripetizione devono memorizzato come un altro file con un numero di serie)

Answer 8

Penso 2 tavoli necessari:

• un tavolo sondaggio per la memorizzazione di domande e le scelte per un nswer. ogni sondaggio verrà archiviato in una riga con un ID sondaggio univoco
• altra tabella è per la memorizzazione delle risposte. Penso sia meglio memorizzare ogni risposta dei clienti in una riga con un ID sondaggio e un id cliente, se necessario.

quindi è possibile calcolare i risultati e memorizzarli in una vista dei risultati del sondaggio.