solution la plus élégante pour le problème humungous

Question

Je travaille sur un site où un utilisateur peut sélectionner certaines dates qui leur sont applicables, par exemple la date 1, Date 2, Date 3, etc.

Chaque jour aura certaines questions Si le client a coché 'Date 1' pour indiquer que cette date s'applique à lui, il verra alors une série de zones de texte l'interroger sur la date 1 et comment elle s'applique à eux. Idem pour toutes les autres dates.

Date 1 et 2 et plusieurs questions, mais les dates restantes ont juste 1 question. Ces dates et leurs réponses seront ensuite utilisées pour créer des rappels personnalisés pour le client et envoyés à lui.

Je voudrais aussi un design qui le rend simple (ou aussi simple que possible) pour ajouter des dates et des champs supplémentaires.

Ma question est, quelle est la meilleure façon de stocker toutes les dates et leurs réponses liées à l'utilisateur dans la base de données? Je pensais que dans le tableau user, j'ai boolean colonnes à partir de Date 1 - Dernière date (de toute évidence, ils ne sont pas réellement nommés date 1, date 2, etc.). Si la colonne pour Date 1 est définie sur 0, cela signifie que le client ne l'a pas coché, et si c'est 1, alors cela signifie qu'il l'a fait et il a répondu aux questions pour cela.

En ce qui concerne le stockage réel des dates, je considère ces deux options:

1) 1 table pour chaque date, avec des colonnes pour chaque question posée à cette date et une colonne user_id. Donc, dans Date_1 tableau, je vais avoir des colonnes comme Q1_name, Q2_name et les réponses aux questions que l'utilisateur a donné.

Mais je veux quelque chose de plus élégant parce que 1), il sera difficile d'aller chercher toutes les réponses de l'utilisateur lors du calcul de quelle information. s'applique à eux lors de l'envoi des emails personnalisés. 2) Certaines dates ont seulement 1 question, donc ce sera moche de créer une table à part entière pour eux.

2) Une table user_answer, avec les colonnes:

user_id,date_name,question_name,answer_val 

2 semble jusqu'à présent le plus élégant, mais il devrait y avoir une meilleure solution. Des pensées?

Answer 1

On dirait que vous voulez quelque chose comme la structure de la table (de base) suivante:

• utilisateur - userId, userInfo
• Date de-dateId, dateInfo
• Question - questionId, questionInfo
• UserDate - userId, dateId - ce stocke toutes les dates applicables pour un utilisateur donné et représente le nombre de plusieurs entre les utilisateurs et les dates - un utilisateur peut avoir plusieurs dates et une date peut avoir de nombreux utilisateurs
• DateQuestion-dateId, questionId - ce stocke toutes les questions qui s'applique pour une date donnée et représente la relation plusieurs à plusieurs entre Dates et Questions - une date peut avoir beaucoup de questions et, je suppose, une question peut être utilisée contre plus d'une date
• UserResponse - userId, questionId, questionResponse - this store toutes les réponses des utilisateurs à toutes les questions posées. Si vous avez besoin de savoir à quelle date la question s'applique, en supposant qu'ils peuvent répondre à la même question plus d'une fois pour plusieurs dates, ajoutez une colonne dateId.

Answer 2

Option 2 semble proche de la bonne solution, mais je voudrais remplacer date_name et question_name avec date_id et question_id.
Une solution optimale, et la plus simple qui permet d'ajouter de nouvelles questions et dates semble être:
1. Table des dates avec les champs date_id, title, date.
2. Table des questions avec les champs question_id, date_id, title (et éventuellement taper la réponse et la description).
3. Répond au tableau avec question_id et answer.

Vous devrez également décider si vous avez des questions communes à plusieurs dates et ce qu'il faut faire dans ce cas. (vous pouvez vouloir deux réponses différentes, ou une réponse commune). Je recommanderais contre la première solution, cela rendrait la question non dynamique - vous auriez à changer la structure de sql et de table pour chaque changement dans les questions ou les dates.

Answer 3

Je pense que vous avez à peu près obtenu, la seule chose est que vous pourriez peut-être séparer les noms de question et la date dans une table séparée, vous donnant le schéma suivant:

utilisateur: id, ... (nom, date de naissance, nourriture préférée, etc.)
datename: id, name (appelé datename donc pas en conflit avec le mot date, ce qui pourrait signifier quelque chose d'autre dans SQL)
question: id, date_id, text
UserAnswer: user_id, question_id, answer_val

Il est pas nécessaire de les séparer, mais il y a trois raisons de le faire: 1. LookUps sur les entiers (comme question_id) par opposition au texte (comme question_name) est beaucoup plus vite parce que les nombres entiers sont plus petits et fixes. 2. Si vous changez le texte en question (comme pour corriger une faute d'orthographe), il vous suffit de modifier une seule entrée dans Question, plutôt que sur chaque ligne. 3. Parce que vous stockez chaque bit de texte une seule fois, vous économisez beaucoup d'espace. Le stockage de 1000 entrées est plus petit que le stockage de 1000 chaînes. Tant que les cordes sont plus longues que quelques caractères. En outre, je pense que cela pourrait très bien fonctionner.