Web Form - Multiple tabs - how to store in database?

Our site has a series of eForms that a user fills out.  Some of the forms are very long.  They want to be able to have tabs at the top of the page where they can go from one form to the next and back again for more system flexiblity.  Currently, each for the forms has it's own file and it's own corresponding table in the database.  

The site is programmed in asp (not .net).  I have an idea that to create the tab format and to be able to retain all the fields as they move from one tab to the next I'll need to combine some of the files into one file and then display or hide depending on which tab they've clicked.  But when they save the form as a whole - I'm unsure if it's more efficient to save all the fields to one table or to break up the form into several smaller logical tables.

Currently, each of the tables has about 100 fields.  If I start combining them I feel like the table structure is getting out of control.  

Does anyone have any advice on how I'm going to set this up?
Who is Participating?
The database structure to how the web forms are populated should have little effect on how to navigate thru your system.  IN a true object oriented approach, your web application should be using bean classes and passing those back and for thru your system.  Once the user has finished their transaction, then you should save (persist) to the dabase.

Each application is different, but the jest of the tables would to be have a parent and then children tables to save on storage and also to eliminate saving the same information over and over.  

So lets say you have site about poeple who collect cars.  I would first define my objects (which later become beans most times) and would make one for the user, for the car, for the address and contact information.  When the user first logged on would collect the user information on page and save in a bean, then collect the car information and save it in a bean, then finally the contact information.  They when finished all three items, would persist (save) to database).  

On occassion you may not want to wait until everything is done to save, so you save it in stages which then in turn helps out with having children tables.  Going back to the example just mentioned.  Could have user first put in user information and then save to user table, then enter car information and then save to a car table when also has the key to the user table, and then finally the contact information save.

Many ways to skin the cat on this.  More saving to database slows responses sometimes, but also ensures if session goes down... they trip over power cord and unplug machine, they dont lose everything.  You the designer have to determine the units of work to be saved.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.