If your app’s data set isn’t expected to get big, don’t sweat it too much, most ways will work fine. It’s just if you expect to scale to large numbers that structure comes into play.

Things I think about are…

  • Keep “like” data together and split out (ie “normalize”) data when reasonable
  • Keep entries data light (normalization helps here)
  • Know who should be the parent and who the child
  • Aim for simplicity and elegance, go complex only as needed

From a quick look at your situation, if each user shares the same questions, what comes to mind as a structure is below:

  • User datatype
  • Question datatype (assuming users are submitting unique answers to shared questions)
  • Answer datatype (assuming each answer is unique to each user)

The Answer datatype has two custom fields: Question (connects the Answer to the right question) and User (connects the answer to the user who wrote it).

However if each question is unique to each user, then you’d have a Question & Answer datatype that contains both the question and the answer, with a custom field connecting it to the User.

I think this would keep the database the “lightest” – but as mentioned, you’ll also want to think about what you are doing with the data in search and display, as that sometimes calls for other approaches.

1 Like