The most suitable approach will heavily depend on the kind of database you consider.
In the relational DB, you should have a table for each entity, so
QuestionChoice. You could have a table for
QuestionType but you could also use a hard-coded property (especially if your program foresees specific behavior depending on the type of question):
Question would have a field
Survey_id to make the link to the
Survey. And similarly,
QuestionOption would have a field
In this way, you could easily add an entity for users, an entity for keeping track of the user participation in survey (e.g. date of participation), and the answer to a question.
And it's then easy to combine information in different tables by using join.
NoSQL Document database
As you mention JSON, you could also make use of a NoSQL document database like MongoDB, which often have a tight relation with JSON.
In this case you could be tempted to have one document for
Survey, which has a collection of
Questions, which have a collection of
QuestionChoice. With this scheme, it's easy to load a questionnaire. However, combining information (e.g. questions together with user answers) is much more difficult and needs programming.
Alternatively, you could also use a table like approach, with different documents and references from the main document to related documents. As it is more complex to maintain, you'd go for this approach only if performance issues would need it.