Speed and efficiency - one database file or two?

[Peter T]

I am developing 7 web based questionnaires - with data being stored in FMP databases - using FileMaker Pro 6 Unlimited.

Several of the databases have very similar structures/questions - what I want to know is would it be better to have one database for each questionnaire or to have several questionnaires sharing the same database (though not using all the fields).

I want to minimise the server response times - will have thousands of respondents - keen that they get their pages served up to them as rapidly as possible.

The server is only being used to host FMP driven websites - has about 6 active databases at present.

Thanks - in anticipation! :)

[Peter T]

I am developing 7 web based questionnaires - with data being stored in FMP databases - using FileMaker Pro 6 Unlimited.

Several of the databases have very similar structures/questions - what I want to know is would it be better to have one database for each questionnaire or to have several questionnaires sharing the same database (though not using all the fields).

I want to minimise the server response times - will have thousands of respondents - keen that they get their pages served up to them as rapidly as possible.

The server is only being used to host FMP driven websites - has about 6 active databases at present.

Thanks - in anticipation! :)

[Peter T]

I am developing 7 web based questionnaires - with data being stored in FMP databases - using FileMaker Pro 6 Unlimited.

Several of the databases have very similar structures/questions - what I want to know is would it be better to have one database for each questionnaire or to have several questionnaires sharing the same database (though not using all the fields).

I want to minimise the server response times - will have thousands of respondents - keen that they get their pages served up to them as rapidly as possible.

The server is only being used to host FMP driven websites - has about 6 active databases at present.

Thanks - in anticipation! :)

[Ender]

Welcome Peter,

It's generally better to combine tables that have similar data. It makes it much easier to modify the interface (once rather than seven times) and do reporting on the answers later.

Performance is unlikely to be a problem until you get into hundreds of thousands of records.

[Ender]

Welcome Peter,

It's generally better to combine tables that have similar data. It makes it much easier to modify the interface (once rather than seven times) and do reporting on the answers later.

Performance is unlikely to be a problem until you get into hundreds of thousands of records.

[Ender]

Welcome Peter,

It's generally better to combine tables that have similar data. It makes it much easier to modify the interface (once rather than seven times) and do reporting on the answers later.

Performance is unlikely to be a problem until you get into hundreds of thousands of records.

[Steve T.]

Howdy, P! If it were me, I'd probably make 1 db for answers and 1 db for questions (each with about 50-100 fields rather than 1 record per question or answer) for FMPro, but it depends on your questionnaires. If you are presenting long/complicated questions 1 at a time, then I might go with 1Q/1A instead and just carry an ID of some kind to link all of 1 person's data all together. Assuming you're not, though, and the questions are relatively quick and simple, then I'd present about 10 at a time with the 1st set creating the record (-new) while the others just edited the same record for any particular set.

I think Garry Claridge posted a sample quetionnaire somewhere in the posts that had all the code and everything... It may be worth a looksee since he gives some of the best help on the boards here. Look for posts of his that mention questionnaire or survey.

--ST