How to properly organize the storage of similar but different data in the database?

Question

SQL

Hello, please tell me how to organize the storage of similar data in the database?
As an example: Testing system: A test can have a number of questions, questions can be of three types:

• As an answer, you will need to enter the line
  
• As an answer, you will need to choose one of the proposed options (radio)
  
• As an answer, you will need to choose one or more of the suggestions. options (checkbox)
  

How to properly organize their storage in the database?
A couple of options come to mind:
1. Make 3 tables for storing questions and three tables for linking (Test - Question). So it will turn out to set up a rule at the base level that the radio is one answer, and the checkbox is more than one.
2. Make 2 tables for storing questions and one for linking (Test question), where as a parameter there will be a pointer to one of the tables with questions. It will not be possible to set up a foreign key rule here, since one table will link a table with tests and two tables with questions), there is also no rule at the database level whether a question with radio can have more than one answer.
Which option is correct? Maybe some intermediate solution?
Also a question about EntityFramework (Code second), is it possible to link models (test - question) with the second option? And if you use the first option, then the "Test" model will have three arrays with questions (one for each type)?

Answer 1

This is how I see it as an artist
[Tests]
Id | name | DateCreate | IsDeleted and also, what attributes do you need there to store the list of tests
[Questions]
Id | TestId | question text | Answer Text | IsDeleted + your attributes, what you need
[Answers]
Id | QuestionId | Answer Text | IsCorrect (is the answer correct or just an option) | IsDeleted etc.
How it will work:
1. take a test
2. take the Nth question for this test from the table of questions
3. take K answers for the Nth question. Option 3:
I think I understand you. Let's take my example, and you will say, this or not.
Online electronics store. Smartphones have properties (memory, screen, battery capacity), and vacuum cleaners (power, wire length, number of nozzles). Objects are similar (products), but properties are different and different quantities
I did this:
[Item] --item
Id | name | CategoryId | cost | etc.
[PropTypes] --property types
Id | name | Measure (the unit of measure that will be signed. Type "Mb", "W", "L", "km/h"), etc.
[ItemProps] --properties possessed by the item
Id | ItemId | typeId | etc.
[PropValues] -
Id property values ​​| PropId | num value | text value | bool value | dateValue
You can, of course, cut PropValues ​​into 4 tables, and store each type separately. But it is possible and so. Or write a trigger that only one field out of 4 can be filled (numValue | textValue | boolValue | dateValue).
Or take it into account in the code (less preferred)