Совет, необходимый для нормализации базы данных - PullRequest
Новая
       8

Совет, необходимый для нормализации базы данных

2 голосов
/ 24 марта 2010

Я пытаюсь создать базу данных для приложения обратной связи в ASP.net У меня есть следующий дизайн базы данных. 

Username (PK)

QuestionNo (PK)
QuestionText

FeedbackNo (PK)
Username

UserFeedbackNo (PK)
FeedbackNo (FK)
QuestionNo (FK)
Answer
Comment

пользователь имеет уникальное имя пользователя пользователь может иметь несколько отзывов

Мне было интересно, нормализован ли дизайн базы данных, который у меня здесь есть, и подходит ли он для приложения

РЕДАКТИРОВАТЬ - обратная связь содержит несколько вопросов, поэтому будет более одного ответа обратной связи. надеюсь, что это имеет смысл

РЕДАКТИРОВАТЬ - у меня есть 20 вопросов в форме обратной связи, на каждый вопрос можно ответить с помощью переключателя (отсюда и поле «Ответ»), и к каждому вопросу можно добавить дополнительные комментарии. пользователь может заполнить эту форму обратной связи столько раз, сколько он хочет. Вот почему у меня есть таблица ссылок, у которой есть feedbackNo и имя пользователя.

РЕДАКТИРОВАТЬ 

**Users Table**
UserID (PK) autonumber
Username

**Question Table**
QuestionID (PK) autonumber
QuestionNumber
QuestionText

**Questionnaire Table**
QuestionnaireID  (PK) autonumber
UserID (FK) `User Table`
Date

**Feedback Table**
ID (PK) autonumber
QuestionnaireID (FK) `Questionnaire Table`
QuestionID (FK) `Questions Table`
Answer
Comment

после прочтения комментариев ... я бы перестроил свой дизайн, подойдет ли этот новый дизайн для моих нужд?

Ответы [ 5 ]

3 голосов
/ 24 марта 2010

Я бы пошел с чем-то вроде: 

Users
UserID         int     primary key auto number/identity
UserName       

Questions
QuestionID     int    primary key auto number/identity
QuestionNumber
QuestionText   

Feedback
FeedbackID     int    primary key auto number/identity
QuestionID     int    fk 
UserID         int    fk
Answer
Comment

Я бы посоветовал поместить столбцы LastChgDate и LastChgID FK в каждую таблицу, возможно, даже CreateDate и CreateUserID. Вам не понадобится специальный столбец в любой из этих таблиц для воссоздания порядка вставки, для этого подойдут автоматические числа / идентификационные значения (хотя и не всегда непрерывные являются инкрементными).

Я бы не использовал GUID и строковые ключи (например, Имя пользователя), так как каждый индекс будет занимать больше памяти. Я бы использовал суррогатный ключ вместо имени пользователя, потому что он может быть изменен (развод / брак / и т. Д.).

Таблица обратной связи немного беспокоит, это для ответов или комментариев? возможно, должно быть две таблицы или, по крайней мере, столбец FeedBackType и один текстовый столбец. ОП не дает достаточно информации, чтобы полностью ответить на этот вопрос. Даже после редактирования ОП я не уверен, что понимаю: a feedback has multiple questions, so there will be more than one feedback answer

3 голосов
/ 24 марта 2010

У вас там посторонний стол. Похоже, у вас есть отношения многие-ко-многим между отзывами и пользователями. Однако отзывы относятся только к одному пользователю. Количество элементов должно быть:

  • Один пользователь за отзыв
  • Один вопрос за отзыв

Ваша структура должна выглядеть так:

Таблица пользователей

Имя пользователя (PK)

Таблица вопросов

Id (PK)
QuestionText

Таблица отзывов

Id (PK)
Имя пользователя (FK)
QuestionID (ФК)
Ответ
Комментарий

С предоставленными обновлениями c11ada дизайн стоит. Единственное отличие, которое я могу сделать в вашем случае, заключается в том, что я буду хранить дату и время ответа в таблице отзывов.

Альтернативой может быть создание другой таблицы, таблицы Анкеты, в которой будет записан экземпляр обратной связи, заполненной пользователем.

Таблица анкет

Id (PK)
Имя пользователя (FK)
Дата

Таблица обратной связи

Id (PK)
Опросный лист (ФК)
QuestionID (ФК)
Ответ
Комментарий

Предполагается, что анкета не относится к другому пользователю. В этом случае это будет выглядеть так:

Таблица анкет

Id (PK)
AboutUser (FK)
Автоответчик (ФК)
Дата

2 голосов
/ 24 марта 2010

Во-первых, обычно неправильно вводить значение пользователя в качестве первичного ключа. Например, что произойдет, если вам придется изменить имя пользователя?

Лично я бы пошел с чем-то вроде этого: 

User_ID (PK) (GUID)
UserName

Question_ID (PK) (GUID)
QuestionNumber
Question

Feedback_ID (PK) (GUID)
Question_ID (FK)
User_ID (FK)
FeedbackDate
FeedbackText

Кроме того, ответы и комментарии независимы друг от друга? Вы можете рассмотреть вопрос о наличии таблицы ответов и таблицы комментариев.

РЕДАКТИРОВАТЬ: FeedbackDate для целей заказа. Это естественный сортировщик по сравнению с ведением индекса заказов.

1 голос
/ 24 марта 2010

Основываясь на ваших изменениях, я думаю, что ваш дизайн верный - таблица отзывов представляет собой набор вопросов / ответов для пользователя, где последняя таблица определяет отдельные ответы. Я бы не включил слово «Пользователь» в имя последней таблицы / PK, поскольку именно таблица Feedback определяет пользователя. Назовите это как «FeedbackAnswer».

Кроме того, вы смешиваете суррогатные ключи и натуральные ключи (имя пользователя - ключ, а FeedbackNo - ключ). Это вопрос спора о том, что лучше, но я уверен, что больше людей согласятся, что вы должны придерживаться одного или другого подхода, а не смешивать их (если это возможно).

Наконец, если пользователь должен выбрать ответы из списка возможных ответов, подумайте о наличии таблицы QuestionAnswer, которая определяет ответы на каждый вопрос, который затем будет относиться к таблице FeedbackAnswer и лучше нормализует данные ответов.

0 голосов
/ 24 марта 2010

Звучит так, как будто нормализовано. Вопрос к обратной связи 1-1? Если это так, убедитесь, что у вас есть уникальное ограничение на таблицу UserFeedback, которая включает FeedbackNo и QuestionNo.

...