Sulla base di ciò che hai detto, utilizzerei il seguente schema generale:
CREATE TABLE [dbo].[PollQuestion]
(
[PollQuestionId] INT NOT NULL PRIMARY KEY IDENTITY,
[QuestionText] NVARCHAR(150) NOT NULL, -- Some reasonable character limit
[Created] DATETIME2(2) NOT NULL DEFAULT SYSUTCDATETIME(),
[Archived] DATETIME2(2) NULL, -- Remove this if you don't need to hide questions
)
CREATE TABLE [dbo].[PollOption]
(
[PollOptionId] INT NOT NULL PRIMARY KEY IDENTITY,
[PollQuestionId] INT NOT NULL, -- Link to the question here because options aren't shared across questions
[OptionText] NVARCHAR(50) NOT NULL, -- Some reasonable character limit
[Created] DATETIME2(2) NOT NULL DEFAULT SYSUTCDATETIME(),
[Archived] DATETIME2(2) NULL -- Remove this if you don't need to hide options
CONSTRAINT [FK_PollOption_PollQuestionId_to_PollQuestion_PollQuestionId] FOREIGN KEY ([PollQuestionId]) REFERENCES [dbo].[PollQuestion]([PollQuestionId])
)
CREATE TABLE [dbo].[PollResponse]
(
[PollResponseId] INT NOT NULL PRIMARY KEY IDENTITY,
[PollOptionId] INT NOT NULL,
[UserId] INT NOT NULL,
[Created] DATETIME2(2) NOT NULL DEFAULT SYSUTCDATETIME(),
[Archived] DATETIME2(2) NULL, -- Remove this if you don't need to hide answers
CONSTRAINT [FK_PollResponse_PollOptionId_to_PollOption_PollOptionId] FOREIGN KEY ([PollOptionId]) REFERENCES [dbo].[PollOption]([PollOptionId]),
CONSTRAINT [FK_PollResponse_UserId_to_User_UserId] FOREIGN KEY ([UserId]) REFERENCES [dbo].[User]([UserId])
)
Non ti interessa davvero se la risposta è un numero, una data, una parola, ecc. Perché i dati sono una risposta a una domanda e non qualcosa su cui devi operare direttamente. Inoltre, i dati hanno significato solo nel contesto della domanda. In quanto tale, nvarchar è il meccanismo più versatile e leggibile per l'archiviazione dei dati.
La domanda e le potenziali risposte verrebbero raccolte dal primo utente e inserite nelle tabelle PollQuestion e PollOption. Il secondo utente che risponde alle domande selezionerebbe da un elenco di risposte (vero / falso = elenco di 2). Puoi anche espandere la tabella PollQuestion per includere l'id utente del creatore, se necessario, al fine di tenere traccia delle domande che creano.
Nella tua UI la risposta selezionata dall'utente può essere legata al valore PollOptionId. Insieme a PollQuestionId è possibile verificare rapidamente che la risposta sia valida per la domanda. La loro risposta, se valida, verrà inserita nella tabella PollResponse.
Ci sono un paio di potenziali problemi a seconda dei dettagli del tuo caso d'uso. Se il primo utente desidera utilizzare una domanda di matematica e non desideri offrire più risposte possibili. Un'altra situazione è se le opzioni fornite dall'utente iniziale non sono le uniche opzioni che il secondo utente può scegliere. È possibile rielaborare questo schema come segue per supportare questi casi d'uso aggiuntivi.
CREATE TABLE [dbo].[PollResponse]
(
[PollResponseId] INT NOT NULL PRIMARY KEY IDENTITY,
[PollOptionId] INT NULL,
[PollQuestionId] INT NOT NULL,
[UserId] INT NOT NULL,
[AlternateResponse] NVARCHAR(50) NULL, -- Some reasonable character limit
[Created] DATETIME2(2) NOT NULL DEFAULT SYSUTCDATETIME(),
[Archived] DATETIME2(2) NULL, -- Remove this if you don't need to hide answers
CONSTRAINT [FK_PollResponse_PollOptionId_to_PollOption_PollOptionId] FOREIGN KEY ([PollOptionId]) REFERENCES [dbo].[PollOption]([PollOptionId]),
CONSTRAINT [FK_PollResponse_UserId_to_User_UserId] FOREIGN KEY ([UserId]) REFERENCES [dbo].[User]([UserId])
)
Vorrei anche aggiungere un vincolo di controllo per assicurarsi che sia fornita un'opzione o una risposta alternativa, ma non entrambe (opzione e risposta alternativa), a seconda delle esigenze.
Modifica: tipo di dati di comunicazione per AlternateResponse.
In un mondo perfetto potremmo usare il concetto di generica per gestire vari tipi di dati per AlternateReponse. Purtroppo non viviamo in un mondo perfetto. Il miglior compromesso a cui riesco a pensare è quello di specificare quale tipo di dati AlternateResponse dovrebbe essere nella tabella PollQuestion e archiviare AlternateReponse nel database come nvarchar. Di seguito è riportato lo schema delle domande aggiornato e la nuova tabella del tipo di dati:
CREATE TABLE [dbo].[PollQuestion]
(
[PollQuestionId] INT NOT NULL PRIMARY KEY IDENTITY,
[QuestionText] NVARCHAR(150) NOT NULL, -- Some reasonable character limit
[QuestionDataTypeId] INT NOT NULL,
[Created] DATETIME2(2) NOT NULL DEFAULT SYSUTCDATETIME(),
[Archived] DATETIME2(2) NULL, -- Remove this if you don't need to hide questions
-- Insert FK here for QuestionDataTypeId
)
CREATE TABLE [dbo].[QuestionDataType]
(
[QuestionDataTypeId] INT NOT NULL PRIMARY KEY IDENTITY,
[Description] NVARCHAR(50) NOT NULL, -- Some reasonable character limit
)
Puoi elencare tutti i tipi di dati disponibili per i creatori di domande selezionando da questa tabella QuestionDataType. L'interfaccia utente può fare riferimento a QuestionDataTypeId per selezionare il formato corretto per il campo di risposta alternativo. Non sei limitato ai tipi di dati TSQL, quindi "Numero di telefono" può essere un tipo di dati e otterrai una formattazione / mascheramento appropriati sull'interfaccia utente. Inoltre, se necessario, puoi trasmettere i tuoi dati ai tipi appropriati tramite una semplice dichiarazione del caso al fine di eseguire qualsiasi tipo di elaborazione (selezione, convalida, ecc.) Sulle risposte alternative.