The design need to be simplified. From your explanation, it seems you only need 3 tables (Questions, Answers, and Feedback) the rest are not needed, since you can JOIN these tables.
Comma separated values are affordable ?
For your design, no you don't need to, and it's not always a good idea to do it. There is some cases you can do it, and might be benefit you, but these are rare cases. Keep things simple and standard, don't join columns or rows into a single value, unless it's a requirement!
So, if your Feedback.Questions meant to store values of questions in comma separated value, I suggest you change that. just give each question a new feedback id, this way it'll be much more manageable. And instead of storing the question string, just store the questionId (FK) instead. this way it'll be more appropriate and would process faster.
So I suggest you remodel it to :
#ListStatus
- Id [PK|IDENTITY]
- Description
#ListRate
- Id [PK|IDENTITY]
- Description
#FeedbackQuestions
- Id [PK|IDENTITY]
- Question
- CreatedAt
- UpdatedAt
- Deleted
- StatusId
- UserId
#FeedbackAnswers
- Id [PK|IDENTITY]
- QuestionId
- Answer
- CreatedAt
- UpdatedAt
- Deleted
- UserId
#Feedback
- Id [PK|IDENTITY]
- RateId
- QuestionId
- AnswerId
- CreatedAt
- Deleted
- UserId
The Listxxx tables would store a list of fixed descriptive values. For instance, ListRate would store the rate options such as Excellent, Very Good, Good, Fair, Poor ..etc. When a user rates an answer, the Id of ListRate would be inserted into Feedback table.
Also, since we defined them with a prefix List it would be standardized in the system design, for general use purpose on other tables, and best yet, easier to understand (so developers would know the purpose of these tables just from the table name).
I got confused between UserId & CustomerId, but I used userId so you're working with logged-in users doesn't matter if is it from Admin or some customer using the system, at the end, you need to record the Username that made this changes .
Another thing you might need is to add a category for the questions, and maybe the Feedback as well. This will be very helpful in filtering the results. You don't want to depend on any column that store user input with open text, it'll be a real pain in the neck. So, adding a category to the questions, which will store it's values in another table to have two columns (one for displaying text for user, the other one is the id) will make things easier to work with, and if you see that you can add more filtering options (either supporting sub-category or tags ..etc) go for it.
Sample :
Questions Table
| Id | Question | CreatedAt | UpdatedAt | Deleted | StatusId | UserId |
|----|------------|----------------------|-----------|---------|----------|--------|
| 1 | Question 1 | 2019-12-14T00:00:00Z | (null) | (null) | 1 | User 1 |
| 2 | Question 2 | 2019-12-14T20:40:15Z | (null) | (null) | 2 | User 2 |
| 3 | Question 3 | 2019-12-14T07:05:01Z | (null) | (null) | 3 | User 3 |
Answers Table
| Id | QuestionId | Answer | CreatedAt | UpdatedAt | Deleted | UserId |
|----|------------|----------|----------------------|-----------|---------|---------|
| 1 | 1 | Answer 1 | 2019-07-05T00:00:00Z | (null) | (null) | User 50 |
| 2 | 1 | Answer 2 | 2019-07-05T00:00:00Z | (null) | (null) | User 50 |
| 3 | 1 | Answer 3 | 2019-07-05T00:00:00Z | (null) | (null) | User 70 |
| 4 | 2 | Answer 1 | 2019-07-05T00:00:00Z | (null) | (null) | User 70 |
Feedback Table
| Id | RateId | QuestionId | AnswerId | CreatedAt | UpdatedAt | Deleted | UserId |
|----|--------|------------|----------|----------------------|-----------|---------|---------|
| 1 | 1 | 1 | 3 | 2019-07-05T00:00:00Z | (null) | (null) | Admin |
| 2 | 2 | 2 | 4 | 2019-07-05T00:00:00Z | (null) | (null) | User 23 |
| 3 | 2 | 1 | 2 | 2019-07-05T00:00:00Z | (null) | (null) | User 5 |
| 4 | 5 | 1 | 3 | 2019-07-05T00:00:00Z | (null) | (null) | User 23 |
