Проектирование базы данных и запросы с MySQL - Не уверен, правильно ли я смоделировал это?

Question

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

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

Если новый клиент входит в магазин:

Store customer info,

If they were referred:

    Make note of name of referrer

Если предыдущий клиент входит:

Retrieve previous customer info,

**If this customer has an un-returned scooter, they can't borrow another

Если клиентарендует скутер, следите за:

Date/hour of borrow,

Date/hour of return,

How much paid, 

Freeform notes that are categorized, ie Issues while scooter is returned or when used

Когда возвращается скутер:

When it was returned,

Is return late, 

Is scooter damaged, 

Additional fees for damage / late return

Запросы, которые я собираюсь сделать в базу данных:

Вселюди, у которых есть флаги,

Все доступные скутеры,

Все заимствованные скутеры,

Все поздние скутеры,

Люди с топ-5 самых рефералов,

Для человека, показать все времена, когда человек одолжил скутер,

Для случая заимствования, показать любые дополнительные сборы, и

Все производители скутеров

Вот то, что я придумал (пока не фактическая диаграмма, только различные таблицы и взаимосвязи), совсем не уверен, что это на правильном пути: https://imgur.com/a/NzqB0CE

Answer 1

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

«Люди, у которых 5 самых популярных рефералов», будут намного проще запрашивать из дополнительной таблицы, упомянутой выше.

Что говорит лиСкутер в настоящее время используется?Возможно скутеры. Доступность?Обратите внимание, что вам, вероятно, потребуется вставить / обновить более одной таблицы, когда Scooter «взят» и когда он «возвращен».

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

Итак, я предлагаю еще около 3 таблиц и переместите несколько столбцов в эти таблицы.

Referrals ...

Вы должны не пытаться поместить массив в столбец.Это грязный, неуклюжий и т. Д. Вместо этого создайте другую таблицу (Referrals) и сделайте ссылку на основную таблицу (Customers).

Когда у вас есть сопоставление «многие к 1» («много» рефералов для «одного» клиента):

Customer:  customer_id MEDIUMINT UNSIGNED NOT NULL, etc
    -- no mention of "referrals"
CREATE TABLE Referrals (
    customer_id MEDIUMINT UNSIGNED NOT NULL,  -- the referree
    name,   -- who referred
    PRIMARY KEY(customer_id, name)
) ENGINE=InnoDB

Это позволяет многим «именам» ссылаться на одного «customer_id».

Если «рефералами» обязательно являются другие клиенты, тоу вас есть таблица «многие ко многим»:

Customer:  customer_id MEDIUMINT UNSIGNED NOT NULL, etc
    -- no mention of "referrals"
CREATE TABLE Referrals (
    ee_id MEDIUMINT UNSIGNED NOT NULL,  -- customer_id of the referee
    er_id MEDIUMINT UNSIGNED NOT NULL,  -- customer_id of the referer
    PRIMARY KEY(ee_id, er_id),
    INDEX(er_id, ee_id)
) ENGINE=InnoDB

Answer 2

правый.Есть некоторые проблемы с вашим дизайном.Идея в SQL DB заключается в том, чтобы «нормализовать» информацию, то есть не дублировать данные.Это одна вещь, которую нужно иметь в виду, другая, это то, что вы должны думать с точки зрения «сущностей» и «отношений» между этими сущностями, а не объектами и действиями.Давайте посмотрим:

CUSTOMER
 -name
 -email

SCOOTER
 -manufacturer
 -model

RENTALS
 -customerID
 -scooterID
 -startDate
 -plannedEndDate
 -actualEndDate

Итак, «АРЕНДА» - это таблица «многие-ко-многим», относящаяся к клиенту, которому можно арендовать много скутеров, и скутеру, у которого будет много клиентов в течение срока службы.customerID и scooterID могут быть автоматическим ROWID из MySQL, или вы можете установить их явно в определенном поле идентификатора.

Из этой настройки вы можете получить много информации, разработав запросы:

Isскутер в наличии?

SELECT * FROM RENTALS WHERE scooterID = X AND plannedEndDate > DATE()

Значит, скутер сдан в аренду и будет возвращен в какой-то момент в будущем.

Есть ли у нас опоздавшие скутеры?

SELECT * FROM RENTALS WHERE plannedEndDate < DATE() AND actualEndDate = NULL

Значит, скутерыкоторые должны были быть уже возвращены, но не вернулись.

И так далее.Надеюсь, это поможет!