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

Question

Предположим, что мне принадлежит бизнес, который продавал автомобили и мотоциклы. Я хочу отслеживать данные по каждому из них. Моя компания предоставляет бесплатную гарантию на каждый автомобиль, но мы даже не предлагаем гарантии на мотоциклы. Первоначально я думал, что есть две таблицы - в «Транспортные средства» таблица и «ГАРАНТИЙ» стол, как этот

Vehicles              Warranties 

VehicleID, SalePrice, VehicleType, WarrantyID    WarrantyID, EffDate, ExpDate 

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

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

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

(Примечание: Я также сделать предположение о том, что 2 или 3 машины могли бы использовать одну гарантию.)

Что такое правильный способ создать эту базу данных?

Answer 1

Храните мотоциклы и автомобили в одном и том же столе.

Это абсолютно обычное разрешение, чтобы столбец был NULL, если атрибут не относится к типу данных в данной строке. NULL предназначен для «неизвестных, отсутствующих или неприменимых данных».

Answer 2

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

Vehicle    VehicleWarranty   Warranty 
---------   ---------------   ---------- 
VehicleId   VehicleId    WarrantyId 
SalePrice   WarrantyId    EffectiveDate 

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

Answer 3

Нет надлежащего способа, оба подхода действительны. Это зависит от того, что такое бизнес.

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

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

Answer 4

Это зависит от того, что вы собираетесь делать на таблицах.

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

Но если вы не собираетесь смешивать их, вы можете использовать второй.

Я бы выбрал первый, так как он позволит вам предлагать гарантию на велосипеды в будущем.

Answer 5

Если гарантия не является обязательной для некоторых транспортных средств, и ваше предположение не является обязательным требованием, вы можете поместить FK в гарантийный талон.Следующее также предполагает, что между Транспортным средством и Гарантией существует одно к одному (если оно существует).

Vehicle    Warranty 
---------   --------------- 
VehicleId   VehicleId 
SalePrice   EffectiveDate 

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

Сложно сказать, что лучше, не зная ваш шаблон запроса.