Según lo que ha dicho, usaría el siguiente esquema general:
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])
)
Realmente no le importa si la respuesta es un número, una fecha, una palabra, etc., porque los datos son una respuesta a una pregunta, no algo en lo que necesita operar directamente. Además, los datos solo tienen significado en contexto para la pregunta. Como tal, nvarchar es el mecanismo legible por humanos más versátil para almacenar los datos.
La pregunta y las posibles respuestas se recopilarían del primer usuario y se insertarían en las tablas PollQuestion y PollOption. El segundo usuario que responde las preguntas seleccionaría de una lista de respuestas (verdadero / falso = lista de 2). También puede expandir la tabla PollQuestion para incluir la identificación de usuario del creador, si corresponde, para rastrear las preguntas que crean.
En su IU, la respuesta que selecciona el usuario puede estar vinculada al valor de PollOptionId. Junto con el PollQuestionId puede verificar que la respuesta sea válida para la pregunta rápidamente. Su respuesta, si es válida, se ingresaría en la tabla PollResponse.
Hay un par de posibles problemas dependiendo de los detalles de su caso de uso. Si el primer usuario quiere usar una pregunta matemática y no desea ofrecer múltiples respuestas posibles. Otra situación es si las opciones que proporciona el usuario inicial no son las únicas opciones que el segundo usuario puede elegir. Puede volver a trabajar este esquema de la siguiente manera para admitir estos casos de uso adicionales.
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])
)
Probablemente también agregaría una restricción de verificación para asegurarme de que se proporcione una opción o una respuesta alternativa, pero no ambas (opción y respuesta alternativa), según sus necesidades.
Editar: Comunicando el tipo de datos para AlternateResponse.
En un mundo perfecto, podríamos utilizar el concepto de genéricos para manejar varios tipos de datos para la Respuesta Alternativa. Por desgracia, no vivimos en un mundo perfecto. El mejor compromiso que se me ocurre es especificar cuál debería ser el tipo de datos AlternateResponse en la tabla PollQuestion, y almacenar AlternateReponse en la base de datos como un nvarchar. A continuación se muestra el esquema de preguntas actualizado y la nueva tabla de tipos de datos:
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
)
Puede enumerar todos los tipos de datos disponibles para los creadores de preguntas seleccionando en esta tabla QuestionDataType. Su interfaz de usuario puede hacer referencia al QuestionDataTypeId para seleccionar el formato adecuado para el campo de respuesta alternativo. No está limitado a los tipos de datos TSQL, por lo que "Número de teléfono" puede ser un tipo de datos y obtendrá el formato / enmascaramiento adecuado en la interfaz de usuario. Además, si es necesario, puede enviar sus datos a los tipos apropiados a través de una declaración de caso simple para realizar cualquier tipo de procesamiento (selección, validación, etc.) en las respuestas alternativas.
