I''ve sat on the sidelines dreaming of doing something with Rails for far too long, it''s high time I dove in and wrote something. For my day job I''ve created some crude Python scripts and database methods in Zope that generate survey questions based on a ''questions'' table and an ''answers'' table. The scripts at this point are waaay too stupid to handle putting the storing the results back into the database, that I handle with further survey-specific scripts and database methods. I dream of writing a Rails version, both to satisfy my desire to give Rails a spin, and in hopes it will help convince my employer to ditch Zope entirely. To accomplish my second goal, this should be a lot smarter than the pretty stupid Zope version. When all is said and done with it, all I want to have to do to make a new survey is set up some questions and answers, embed the barest snippet of code in an html form where I want a question to appear, and then sit back and let Rails take it from there. I can envision how to translate the Python and sql methods I have now into Ruby versions to get the app asking the right questions for me. Where I''m stuck is on how to put the results back into a table. As I see it, I can take two approaches to laying out my results table and telling Rails how to save answers: short and wide or long and tall. Short and wide would be to have a table laid out with a single row per person, with each question getting its own column. The app would look at the questions table, note the type of question (whether it will result in an integer, a big chunk of text, etc), and create the results table from that. Storing the results is then just a matter of directing each answer into the right column. Long and tall has one row per question, with a column for person, question, and answer (which be a suitably generic column type like text or blob). All the app has to do is take each answer and slap it into a row. I can see advantages to each approach. Short and wide requires more work to store results, but less to pull them out in a useable format for analysis. Long and tall would likely be easier store, but harder to pull out results to analyze. My question is which is the technically-superior way? Which is the "better" database design? Is there a way to do this I haven''t even thought of that blows both ideas out of the water? Thanks! -Dane Jensen