I think some of those questions can't really be answered by us as we don't fully know what you want to do with your survery results.
A table for respondants, even if the only field is a UserID may still be useful to you. It could make it easier to review all the results for a given individual, it could help you tell if the survey from that individual is complete. Is it necessary? Probably not but only you know what specific kinds of analysis need to be performed on your results.
What "coded responses" are these? Do you mean that you have a list of codes and a response description for each and you need to review the open ended responses and use this table to select a code for each such response? That sounds like you'll need a table for the coded response list.
The database will be used to import survey responses (not for actually taking the survey). Then we will read and code the open-ended responses. On the open-ended questions, we will actually need to have the option of selecting multiple codes per response. Some of the codes will be pregenerated, but we will also need to edit as we read through the responses.
For instance, we ask respondents to describe X. Then we need a field where we choose a category from a drop down list for that description. We will also have several other fields where we can select characteristics used to describe X (and add to the drop down list when necessary). So, a description could have one field coded if it's a very short description, or it can have 9 fields coded if it is a long description with a lot of characteristics. The goal is to be able to run some analysis on the number of times certain descriptions show up across any of the 9 fields.
So I'm wondering if the coded responses should go in a separate table? I would like to also track who is creating the codes automatically. I'm thinking the answer is yes, but wanted to double check.
Thanks for the answer on respondents. That makes sense and could be helpful.
If you have more than one response code to assign to a single response, then a related table will allow you to count the responses and this will be difficult to do if you do not.
I have 4 questions whose responses will be set up this way. Should I do a separate table for the coding of each question? Or can I have one table that has all the codes in it?
I would think you can use a single table. You can use a portal to log the multiple codes from a layout based on the response records. Since the relationship will auto-enter the ResponseID, you'll be able to tell which Code record goes with which response so that you can break things down by response or lump them all together simply by how you do finds and sorts on this unified table.