Sur la base de ce que vous avez dit, j'utiliserais le schéma général suivant:
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])
)
Vous ne vous souciez pas vraiment si la réponse est un nombre, une date, un mot, etc. parce que les données sont une réponse à une question et non quelque chose que vous devez utiliser directement. De plus, les données n'ont de sens que dans le contexte de la question. En tant que tel, un nvarchar est le mécanisme lisible par l'homme le plus polyvalent pour stocker les données.
La question et les réponses potentielles seraient recueillies auprès du premier utilisateur et insérées dans les tables PollQuestion et PollOption. Le deuxième utilisateur qui répond aux questions sélectionnerait dans une liste de réponses (vrai / faux = liste de 2). Vous pouvez également développer la table PollQuestion pour inclure l'ID utilisateur du créateur, le cas échéant, afin de suivre les questions qu'ils créent.
Sur votre interface utilisateur, la réponse que l'utilisateur sélectionne peut être liée à la valeur PollOptionId. Avec PollQuestionId, vous pouvez vérifier que la réponse est valide pour la question rapidement. Leur réponse, si elle était valide, serait entrée dans le tableau PollResponse.
Il existe quelques problèmes potentiels en fonction des détails de votre cas d'utilisation. Si le premier utilisateur souhaite utiliser une question mathématique et que vous ne souhaitez pas proposer plusieurs réponses possibles. Une autre situation est si les options fournies par l'utilisateur initial ne sont pas les seules options que le deuxième utilisateur peut choisir. Vous pouvez retravailler ce schéma comme suit pour prendre en charge ces cas d'utilisation supplémentaires.
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])
)
J'ajouterais probablement une contrainte de vérification pour m'assurer qu'une option est fournie ou une réponse alternative, mais pas les deux (option et réponse alternative), selon vos besoins.
Edit: communication du type de données pour AlternateResponse.
Dans un monde parfait, nous pourrions utiliser le concept des génériques pour gérer différents types de données pour la réponse alternative. Hélas, nous ne vivons pas dans un monde parfait. Le meilleur compromis auquel je peux penser est de spécifier quel type de données AlternateResponse doit être dans la table PollQuestion et de stocker AlternateReponse dans la base de données en tant que nvarchar. Vous trouverez ci-dessous le schéma de question mis à jour et la nouvelle table de types de données:
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
)
Vous pouvez répertorier tous les types de données disponibles pour les créateurs de questions en sélectionnant dans ce tableau QuestionDataType. Votre interface utilisateur peut référencer le QuestionDataTypeId pour sélectionner le format approprié pour le champ de réponse alternatif. Vous n'êtes pas limité aux types de données TSQL, donc "Numéro de téléphone" peut être un type de données et vous obtiendrez un formatage / masquage approprié sur l'interface utilisateur. De plus, si nécessaire, vous pouvez convertir vos données dans les types appropriés via une simple déclaration de cas afin d'effectuer tout type de traitement (sélection, validation, etc.) sur les réponses alternatives.