Разработка таблицы SQL и ее правильное использование с первого раза

Question

В настоящее время я работаю над системой отслеживания проблем для своей компании, чтобы помочь им отслеживать проблемы, возникающие в сети. Я использую C # и SQL.

В каждом выпуске есть около двадцати вещей, которые мы должны отслеживать (статус, потеря работы, кто ее создал, кто над ней работает и т. Д.). Мне нужно приложить список команд, затронутых проблемой, к каждой записи в моей основной таблице ошибок. Список затронутых команд в идеале содержит какую-то ссылку на уникальный экземпляр таблицы, как раз для этой проблемы, которая показывает список затронутых команд и какой процент лабораторий каждой команды затронут.

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

Answer 1

То, что вы описываете, называется отношением «многие ко многим». На команду могут влиять многие проблемы, а также проблема может затрагивать многие команды.

При проектировании базы данных SQL для такого рода отношений требуется третья таблица, в которой содержится ссылка на каждую из двух других таблиц. Например:

CREATE TABLE teams (
  team_id INTEGER PRIMARY KEY
  -- other attributes
);

CREATE TABLE issues (
  issue_id INTEGER PRIMARY KEY
  -- other attributes
);

CREATE TABLE team_issue (
  issue_id INTEGER NOT NULL,
  team_id INTEGER NOT NULL,
  FOREIGN KEY (issue_id) REFERENCES issues(issue_id),
  FOREIGN KEY (team_id) REFERENCES teams(team_id),
  PRIMARY KEY (issue_id, team_id)
);

Answer 2

Это звучит как классические отношения многие ко многим ... Вы, вероятно, хотите три стола,

1. Один для вопросов, с одной записью (строкой) для каждой отдельной уникальной проблемы, созданной ...

2. Один для команд, с одной записью для каждой команды в вашей компании ...

3. И одна таблица с именем скажем, "IssueTeams" или "TeamIssueAssociations" `или" IssueActedTeams "для хранения связи между двумя ...

   Эта последняя таблица будет иметь одну запись (строку) для каждой команды, на которую влияет проблема ... Эта таблица будет иметь составной первичный ключ из 2 столбцов для столбцов IssueId и AND TeamId ... Каждая строка должна иметь уникальная комбинация этих двух значений ... Каждое из которых представляет собой внешний ключ (FK) для таблицы вопросов и таблицы команд соответственно.

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

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

Answer 3

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

Мы используем Bugtracker.NET в команде, в которой я работаю. Он был немного изменен, но не было смысла разрабатывать систему с самого начала. Причина, по которой мы выбрали этот продукт, заключалась в том, что он работает в .NET и прекрасно работает с SQL Server, но есть много других альтернатив.

Answer 4

Если я правильно понял вопрос, я бы создал ....

• Таблица ISSUE, содержащая так 20 элементов
• Таблица TEAM, содержащая список команд.
• TEAM_ISSUES таблица, содержащая ссылку между двумя

Таблица TEAM_ISSUES должна содержать внешний ключ к таблицам ISSUE и TEAM (то есть она должна содержать ISSUE_ID и TEAM_ID ... поэтому она действует как пересечение между двумя "основными" таблицами. также место, чтобы поставить процент.

Имеет ли это смысл?

Answer 5

Ну, просто чтобы быть современным и проворным, «сделать все правильно с первого раза» менее модно, чем «рефакторизировать». Но для работы через вашу модель:

У вас есть проблемы (хе-хе). У вас есть команды.

Проблема затрагивает многие команды. На команду влияет много проблем. Так что для решения основной проблемы у вас, похоже, классические отношения «многие: многие». Об этом позаботится таблица соединения, содержащая два столбца: один для Issue PK и один для Team PK.

Тогда у вас есть вопрос, какой% команд. Конечно, в этом есть динамический аспект, поэтому, чтобы сделать это правильно, вам нужно указать триггер. Но очевидное место для этого - столбец Issue («Acted_Team_Percentage»).

Answer 6

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

В вашей базе данных должно быть три таблицы: таблица «Проблемы», таблица «Команды» и таблица присоединения IssueTeams. Таблица IssueTeams будет включать внешние ключи (т. Е. TeamID и IssueID), которые ссылаются на соответствующую команду в командах, а проблемы - в проблемах. Таким образом, Команды по выпуску могут иметь такие записи, как (Issue1, Team1), (Issue1, Team3). Вы можете сохранить процент поражения лабораторий каждой команды в таблице присоединения.

Answer 7

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

Table: Issue
IssueId primary key
status
workLoss
createdby
etc

Table: Team
TeamID primary key
TeamName
etc

Table: IssueTeam
IssueID (foreign key to issue table)
TeamID (foreign key to team table)
PercentLabsAffected

Answer 8

Мы можем видеть эти сущности в вашем домене:

1. " Issue "
2. " Команды ", затронутые этой проблемой, в определенном процентном соотношении

Итак, идентифицировав эти два элемента, вы можете представить это с помощью двух таблиц, а отношение между ними - 1016 * - это еще одна таблица, которая также может отслеживать процентное влияние. Надеюсь, это поможет.

Answer 9

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

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