Блог

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

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

 Member Table:
Id (PK)
MemberId
FirstName
LastName
Email

EquipmentItem Table:
Id (PK)
EquipmentName
EquipmentType (FK)
EquipmentStatus (FK)
TotalQuantity
RemainingQuantity

EquipmentStatus Table:
Id (PK)
StatusName

EquipmentType Table:
Id (PK)
TypeName

EquipmentRentalHistory Table:
Id (PK)
MemberId (FK)
EquipmentId (FK)
CheckOutDate
ReturnedDate
  

1) Я хочу знать отношения между ними. будет ли история аренды отношением «многие ко многим» между таблицей элементов и таблицей EquipmentItem?

2) Будет ли таблица EquipmentItem иметь отношение «один ко многим» между статусом и типом, насколько я понимаю, EquipmentItems может иметь много статусов или типов, но каждый статус или каждый тип может принадлежать только одному EquipmentItem.

3) Имеет ли смысл иметь поле количества в EquipmentItem, я работал в продуктовом магазине, поэтому я основываю логику на штрих-кодах, где одни и те же продукты обычно имеют один и тот же штрих-код, например (чипсы Cheetos Puff) все чипсы Cheetos Puff будут иметь один и тот же штрих-код, но будут иметь количествозначение в нем. Или было бы лучше, чтобы каждый элемент был уникальным, независимо от того, является ли он одним и тем же продуктом / моделью?

Моя логика была бы:

1. участник сдает товар в аренду
2. система регистрирует его в таблице истории
3. затем система проверяет, сколько из одного и того же элемента было извлечено до сих пор, если, скажем, у нас общее количество 4 по этому элементу, и 3 участника его проверили
4. мы обновляем поле оставшегося количества до разницы, поэтому в данном случае до 1
5. затем система может отслеживать, у кого что было извлечено, возвращая все записи с возвращенной датой null
6. затем система проверит все записи с возвращенной датой null, а затем выполнит диапазон дат в извлеченную дату, чтобы определить, просрочено ли оборудование
7. отправка уведомлений на электронные письма участников, связанные с указанными записями, начиная с шага 6

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

Чтобы ответить на ваши вопросы

1. Что касается моделирования в ERD, я не думаю, что это квалифицируется как отношение «многие ко многим», а скорее EquipmentRentalHistory является его собственной сущностью, которая имеет отношение «многие ко многим» с обоими Member и EquipmentItem .

   «Многие ко многим» было бы больше похоже на «a Member имеет доступ к 0 … n EquipmentItems , и к каждому EquipmentItem может быть доступно 0 … n Members «.

2. Я бы не согласился с тем, что это отношения «один ко многим».

   Кислородный баллон и пара ласт могут быть классифицированы как «Снаряжение для подводного плавания» и иметь статус «Проверено».

   У вас может быть несколько тегов «Снаряжение для подводного плавания» и присвоить каждому уникальному тегу «Снаряжение для подводного плавания» свой собственный EquipmentItem , но тогда вы просто будете создавать новые теги для каждого нового EquipmentItem , а не повторно использовать существующие.

3. Это действительно зависит от того, хотите ли вы точно определить, какое оборудование арендовал участник (может быть, что-то повреждено, вы можете отследить всех, кто арендовал это конкретное оборудование?). Если вы дифференцируете, то каждый элемент будет просто отдельной строкой. Вам также следует добавить новый столбец в качестве внешнего идентификатора, но вести учет не потребуется.

   Если вам все равно, то я бы сохранил только total , но не available . Если бы вы сохранили available столбец, вам постоянно приходилось бы обновлять его всякий раз, когда что-то регистрируется EquipmentRentalHistory . Это будет раздражать, если таблицы не синхронизированы. Вы могли бы просто запросить EquipmentRentalHistory Id количество оборудования и подсчитать записи where для количества оборудования, returnedDate IS NULL которое используется в данный момент

Дополнительное примечание

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