Нужны отзывы о дизайне БД

Question

В настоящее время я работаю над системой продажи билетов, которая позволяет нашим пользователям отправлять билеты в зависимости от их потребностей. то есть, если Департамент «А» подает заявку, он может иметь определенные типы проблемных категорий (например, «Расходные материалы» или «Принтер») вместе с деталями, относящимися к выбранной категории. Я выложил частичный дизайн БД и искал отзывы. Я никогда не создавал систему с нуля, поэтому немного нервничаю.

вот мой черновой вариант моего дизайна БД

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

Id | CreatedBy | CreateDate | Status | Owner | AssignedTo | AssignmentDate | 
-----------------------------------------------------------------------------

Таблица предметов оборудованияДетали

Id | IssueId | Serial # | Make | Model | ....
---------------------------------------------

Таблица SupplyIssueDetails

Id | IssueId | SupplyId | ItemId | QTY | UnitOfMeasurement
-------------------------------------------------------------

Таблица NetworkIssueDetails

Id | IssueId | Supervisor |  Details | 
-------------------------------------------------------------

Таблица примечаний

Id | IssueId | Note | CreatedBy | CreateDate
-------------------------------------------------------------

Заранее спасибо

Answer 1

Я бы разделил вашу таблицу «Проблемы», чтобы задачи и задания были отдельными. Кроме того, я бы добавил таблицу типов проблем и добавил столбец IssueTypeId к проблемам

Вопросы * * 1003 Id, IssueTypeId, Создано, CreateDate, Статус, Владелец IssueTypes

Id, Имя

1011 * Назначение * Id, IssueId, AssignedTo, AssignmentDate, Активный Это позволит нескольким людям быть назначенными на проблему, если потребуется позже. Это также позволило бы записывать историю людей, отстраненных от проблемы. Записи типа проблемы будут выглядеть следующим образом: 1: Оборудование, 2: Поставка, 3: Сеть Возможно, с несколькими разными типами проблем можно было бы справиться, но если у вас их много, замена таблиц «Подробности» на подход таблицы ключей / значений, как это было предложено Ikke, может быть лучше.

Answer 2

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

Не следуйте советам тех, кто считает, что у вас должны быть пары ключ / значение. Такой подход облегчает некоторые вещи, но он быстро превращается в кошмар, когда вы пытаетесь делать другие вещи. В вашем распоряжении мощь полной СУБД. Используйте это!

Каждая строка в каждой таблице представляет истинное суждение о мире. Чем больше дизайн БД может отражать важные реалии, которые вы пытаетесь отследить, тем лучше для вас.

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

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

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

Answer 3

При проектировании начинайте думать о том, как вы собираетесь использовать эти данные. Какого рода отчеты вам понадобятся, как люди будут получать уведомления об изменениях в проблеме, как вы будете выбирать людей, которые будут назначены для выполнения задачи (вам могут понадобиться таблицы для хранения людей, доступных для работы, и их навыков) какие задачи им могут быть назначены), какие вложения вам нужно разрешить и где хранить эту информацию (снимок экрана может очень помочь в решении проблемы). Какие таблицы поиска вам нужны для удаления Ваши заявки? Вам нужен какой-либо вид аудита данных? Вам нужны определенные типы проблем, которые должны быть разрешены руководителем? Могут ли люди автоматически получать уведомления или вам нужно отслеживать, что у них уже есть на планшете, прежде чем определить, кто Доступно. Хотите ли вы иметь возможность определять данные, которые должны быть выполнены для того, чтобы определить, когда наступит опоздание? Вы сказали, что некоторые департаменты могут подавать только определенные виды билетов, где находится таблица для хранения этих данных? Другими словами s, вам действительно нужно погрузиться в суету и выполнить требования.

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

Answer 4

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

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

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