Обратная связь по структуре базы данных - PullRequest
Новая
       20

Обратная связь по структуре базы данных

1 голос
/ 28 июня 2011

У меня есть приложение, которое собирает данные о школах, командах и игроках.могут быть вопросы, заданные на уровне школы, команды и игрока.

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

Дизайн 1

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

Таблицы: 

SchoolQuestions (id, questiontext, length, is_required)
SchoolAnswers(id, school_id, school_question_id, answer)

TeamQuestions (id, questiontext, length, is_required)
TeamAnswers(id, team_id, team_question_id, answer)

PlayerQuestions (id, questiontext, length, is_required)
PlayerAnswers(id, player_id, player_question_id, answer)

Дизайн 2

В этом дизайне все хранится в 2 таблицах.

В поле Questions.type в виде ENUM('SCHOOL', 'PLAYER', 'TEAM')

В таблице ответов:только один из schoold_id, team_id или player_id может быть не нулевым.

Это кажется самым простым решением, но оно имеет избыточные столбцы, поэтому кажется немного грязным

Таблицы: 

Questions (id, type, questiontext, length, is_required)
Answers(id, school_id, team_id, player_id, question_id, answer)

Любая обратная связь приветствуется или предлагает улучшениедизайн, если у вас есть лучшее решение.

Ответы [ 4 ]

3 голосов
/ 28 июня 2011

Дизайн 2 определенно лучше.

Также для поля type может потребоваться создать отдельную таблицу, которая будет иметь 3 строки, и добавить внешние ключи в таблицу вопросов к этой таблице типов.

У вас будет много проблем с дизайном 1:

  • Что если вы решите расширить вопросы еще одним полем? Потребуется обновить более одной схемы таблицы
  • Что если новый тип нужен? Приведет к созданию новой таблицы.
  • Вы не сможете создавать отдельные запросы для запроса разных таблиц вместо одной
  • Вам нужно будет объединить таблицы, если вы хотите узнать, сколько всего вопросов

[EDIT] Пропущены столбцы player_id, team_id и school_id.

Вы можете создать таблицу владельцев, которая будет иметь тип владельца (школа, команда, игрок) со ссылкой на таблицу типов. Таким образом, в таблице ответов будет только один столбец OwnerId.

1 голос
/ 28 июня 2011

Мне нравится второй.

Поскольку вы знаете тип, вы также можете удалить три столбца идентификатора и заменить их одним столбцом универсального идентификатора.

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

Редактировать: ... и, как предлагали другие, добавить таблицу для Type.

0 голосов
/ 28 июня 2011

Определенно дизайн-2 лучше. Но я думаю, что вы можете удалить поля school_id, team_id, player_id из таблицы ответов, так как у вас там есть question_id. С помощью question_id вы можете связать ответы с таблицей вопросов. Ну вот и моя первоначальная мысль. Пожалуйста, исправьте, если я ошибаюсь ..

0 голосов
/ 28 июня 2011

Я лично предпочитаю Design2. Мое мнение, однако, состоит в том, чтобы иметь отдельную таблицу для QuestionType и иметь внешний ключ в вопросах, чтобы ссылаться на конкретный тип вопроса вопроса. Просто помогает выделить немного больше. Во-вторых, я полагаю, я не большой поклонник типов ENUM в базе данных.

Только мои первоначальные мысли.

Удачи.

...