Need help creating a ~300-item web survey

RushNP774 · March 25th, 2009, 02:44 AM

I wasn't sure whether to put this in the "ASP.NET basics" forum or this one. I'm almost done reading "Beginning ASP.NET 3.5 : in C# and VB", so I figured this may be more appropriate here.

I'm building my first real ASP.NET project, and need just a little guidance about the best way to do it. The website is pretty simple, pretty much just a few static pages, but one is going to be a nearly 300-item survey of the activities a person enjoys. The data will be stored in a table (massive one, I know), and I'll perform different statistical analyses on it as I accumulate a large enough sample size.

The survey is set up in four columns:

Name of the activity
A dropdown box populated with a few choices regarding their level of experience
A dropdown box populated with a few choices about their level of interest in the activity
A small input box for comments & additional explanation of their answers for each activity.

As it stands now, I have 45 items set up, and the page is SLOW (both on my computer and in the browser), and bloated. There HAS to be a more efficient way to do it. I'm thinking about generating the form on the fly (because I have the activities loaded into a database table), but don't really know where to start, because I want to be able to easily store all the data in another table record that's created upon submitting the form.

Here are my questions:

Should I go ahead and hard-code 300 items on the form? That would make my page massive, make it very difficult to find the corresponding dropdown & input boxes for my answers when I go to store the form, and it seems like it'd be difficult to change if I wanted to modify my page structure later.
Should I break up the form into multiple pages? That may help the loading times and page sizes, but I have the form broken up by section into a sweet jQuery accordion that works well.
Is there an even more efficient way to do this? There probably is, but I just don't have enough .NET experience to know.
Is a database table with over 600 columns poor database design? Imar doesn't hit on that topic in his discussion of SQL or DB design, but I can't think of any other way to store the data the way I want to.

I don't mind reading tutorials and books (perhaps I should pick up a LINQ & SQL book?), and am not expecting a long, detailed response. Any quick tidbits to point me in the right direction would be MASSIVELY appreciated.

Thanks so much in advance!

Imar · March 25th, 2009, 04:13 AM

Hi there,

Since it's not book related, you're probably better off posting in the ASP.NET Basics. It's more likely that others see your post there as well.

Anyway, a solution like this could be slow if you present all items at once. E.g. if I understand you correctly, you end up with more than 1200 HTML controls in page, with each DDL having its own items. Take a look at the size of the HTML in the browser to see if this could be a problem.

Should I go ahead and hard-code 300 items on the form?

It depends on what they are, how often they change and where they come from. If it's in a DDL, then a database is definitely the way to go. If they are actual questions / rows in the form, that generating them from a database is still an option.

Should I break up the form into multiple pages?
If you're going to have 300 rows, then yes, absolutely. Your users will hate you otherwise. Filling in a 300 question questionnaire in a single page is not fun. The accordion may help, but by splitting it up in multiple pages you can save the results in the database when you move from page to page.

Is there an even more efficient way to do this?
You could use AJAX like techniques to get more questions. E.g. "page" through your list of questions using, for example an UpdatePanel.

Is a database table with over 600 columns poor database design?
It's at least very difficult to work with.... ;-)

What about storing the answers in rows? E.g. store a UserId, QuestionId, then two answers for the DDL controls and one for the TextBox. That way, you only need five columns, and you can have as many rows as required. Also makes it easier to add or remove questions later.

Hope this gives you some ideas.

Cheers,

Imar

RushNP774 · March 25th, 2009, 12:39 PM

Thanks a bunch for the reply Imar. It's really awesome that a book author takes the time to respond to his readers. Please feel free to move this post if you feel it'd be better in the other category, my apologies.

Your suggestions gave me some insight into how to better do this. Let me respond to your answers:

They're probably not likely going to change much, if at all, which is why I was wondering about hard coding. I suppose I could just load the dropdown boxes from a database table or XML file at runtime since I've done that before. Would populating them at runtime from the database be faster for the user than having them hardcoded?
I'll definitely break the survey up, probably into 3-4 sections, and save the responses as I go along. I guess I'd store them all in an array or something, then at the end, let them review their answers (and change them if necessary), and finally submit the data. Makes sense.
The AJAX idea is a good one. Perhaps just use a tab strip or something with an update panel, and either call premade pages or generate the sections on the fly. If I did that, I'd probably just call hardcoded pages because it'd be easier for a newbie like me :) I'd really like to have all the responses on one page, so I'll work on it.
I like your "5-column" table setup, but structured like that, I'm seeing potentially that it may make a bit tough to do what I'd like to do. There are sets of activities & things behind the scenes that I'd like to create subscales for, as well as being able to come up with basic stats (mean ratings, standard deviations, highest/lowest rated activities, etc), which is why I wanted to store everything for one user in a single record. It seems like it'd make it much easier to loop through all the responses for a given category, but maybe with LINQ, this isn't a problem (that's next on my "to read" list).

Thanks again!

Imar · March 26th, 2009, 11:51 AM

In that case, I would probably hard code them. Hard coding will be faster than generating them on the fly as you don't need to access the database.

To make your pages manageable, you could consider storing your questions in User Controls. That way you can group them logically so you don't have to scroll through long pages with questions.

It also makes it easier to make this a multi-page application which is probably the best to do it. If you need all 300 questions, and thus 1200 controls in a single page, you get a huge amount of HTML. and equally important: ViewState.

I would strongly recommend saving changes on each postback in the database. Nothing as frustrating as having your browser crash on question 298..... ;-)

Cheers,

Imar