2010-04-20 8 views
1

Contextesimplificatrices larges, tables non normalisées dans Rails

Je suis la conception d'une application Rails pour enregistrer des données de recherche. La plus grande partie peut être conceptualisée comme étant des données d '«enquête» (ou «questionnaire»).

Nous avons déjà plusieurs bases de données Access et fichiers CSV qui contiennent ces données. La conception existante est que chaque enquête a son propre tableau avec une colonne par question. Beaucoup de ces tables ont des colonnes 100+.

Je viens de recevoir un rapport sur le nombre total de colonnes pour toutes les enquêtes. Le nombre est de . Oui, 18 683 colonnes - un lot plus que ce à quoi je m'attendais. (Je pense qu'il y a plus de colonnes que de lignes, au total, certaines tables peuvent être vestigiales, mais je sais que plusieurs sont très importantes.)

Pour réduire la complexité du problème, j'ai pensé que je ferais certains modèles comme:

  • enquête
  • question
  • Réponse

Cette stratégie réduirait le nombre o f colonnes de milliers à juste une poignée. Cependant, je ne suis pas sûr de savoir comment l'aborder par Rails parce que:

  • Nous avons besoin belles vues (mieux que les formes autogenerating) pour plusieurs des enquêtes.
  • Nous avons besoin validation (certaines enquêtes sont simples, mais d'autres sont assez complexes).
  • Nous devons lier les données à d'autres enregistrements et signaler il. Mes patrons s'attendent à ce que les résultats de chaque enquête soient pivotés (par exemple, une colonne par question) afin qu'ils puissent l'analyser. Y a-t-il une solution élégante pour cela?
  • Le stockage des réponses semble plus difficile qu'avec les tables larges (à moins qu'il y ait une bonne stratégie pour une "colonne polymorphe").
  • ... et d'autres cas où je voudrais probablement traiter chaque enquête comme un modèle ActiveRecord.

Question

Comment puis-je simplifier "Question1, Question2 ..., question143" monstruosité? Bien que je sois sûr qu'il n'y a pas une solution complètement élégante, quel est le meilleur choix?

Je serais intéressé par les bases de données alternatives si elles rendraient les choses plus faciles. Je ne suis pas très familier avec les bases de données de documents (comme mongodb ou couchdb), mais d'après ce que je sais, elles pourraient être utiles.

+0

A atterri ici en cherchant à faire le même type de conversion et curieux de savoir ce que vous avez décidé de faire, un an plus tard. – wesgarrison

+0

Pour ce projet, je me contente d'avoir toutes les colonnes. Si je devais recommencer aujourd'hui, je pense que je ferais CouchDB ou quelque chose de similaire. Le problème pivotant demeure, mais ce n'est pas un problème terrible. –

Répondre

1

Je pense que MongoDB serait une bonne solution pour cela; Il vaudrait certainement la peine de vous familiariser avec cela. La schématisation atténuerait un peu les choses.Par exemple, vous pouvez stocker chaque enquête dans un document ressemblant à quelque chose comme ceci:

survey = {:title => "Thoughts on X", 
      :questions => [ 
      {:text => "What year were you born?", 
      :type => "Fill in the blank", 
      }, 
      {:text => "Pick an option:", 
      :type => "multiple_choice", 
      :choices => ["a", "b", "c", "d"] 
      } 
      ] 
      } 

Vous pouvez alors écrire du code capable d'interpréter ces documents d'enquête et de les présenter sur le web. Vous pouvez certainement inclure des informations de validation spéciales dans chaque document, etc.

Une collection séparée peut contenir des réponses de l'utilisateur. Vous pouvez utiliser Map-reduce de MongoDB pour les agrégations.

Juste quelques idées initiales. Sautez sur la liste d'utilisateurs MongoDB si vous décidez d'explorer cette direction.

Questions connexes