Return to Answer

I agree with Corbin and Ignacio Vazquez-Abrams, and here are some other notes:

The main table Tracker manages different survey name and descriptions.

Then, I'd call it Survey with attributes surveyId, name and description.

The table Card holds information on each person who has been surveyed.

Then, I'd call it SurveyedPerson with attributes surveryPersonId etc.

Survey holds the results of each Card response for the survey being tracked by Tracker and has a unique composite key.

Then, SurveyResult (or Answer) holds the results of each SurveyPerson response for the Survey (being tracked by Survey.surveyId) and has a unique composite key.

In your first question I did not understand the purpose of these tables (see my comment on your first question). I don't know whether your original names are special terms in the field of the survey science or anything but the names above seem easier to understand, read and therefore maintain (for me, at least).

1. Are you sure that you need the Card.trackId attribute? It seems duplication of Survey.trackId (so it's redundant).

2. Are you sure that you don't need to store multiple Surveys (answers) for the same Card (person)? What happens when the same person answers to multiple surveys? Do you duplicate their name?

3. Attribute lengths in the Card table seems too short. You might have problems with the new name of this guy. AFAIK email addresses also could be 254 characters long.

I agree with Corbin and Ignacio Vazquez-Abrams, and here are some other notes:

The main table Tracker manages different survey name and descriptions.

Then, I'd call it Survey with attributes surveyId, name and description.

The table Card holds information on each person who has been surveyed.

Then, I'd call it SurveyedPerson with attributes surveryPersonId etc.

Survey holds the results of each Card response for the survey being tracked by Tracker and has a unique composite key.

Then, SurveyResult (or Answer) holds the results of each SurveyPerson response for the Survey (being tracked by Survey.surveyId) and has a unique composite key.

In your first question I did not understand the purpose of these tables (see my comment on your first question). I don't know whether your original names are special terms in the field of the survey science or anything but the names above seem easier to understand, read and therefore maintain (for me, at least).

1. Are you sure that you need the Card.trackId attribute? It seems duplication of Survey.trackId (so it's redundant).

2. Are you sure that you don't need to store multiple Surveys (answers) for the same Card (person)? What happens when the same person answers to multiple surveys? Do you duplicate their name?

3. Attribute lengths in the Card table seems too short. You might have problems with the new name of this guy. AFAIK email addresses also could be 254 characters long.