База данных и класс дизайна Django

Question

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

class Bike(models.Model): 
    brand = models.CharField(max_length=100) 
    model = models.CharField(max_length=100) 

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

Идея у меня было сделать следующее:

class Wheels(models.Model): 
    description = models.CharField(max_length=100) 
    size = models.DecimalField(max_digits=5,decimal_places=2) 

, а затем включить новое поле в моем велосипеде:

class Bike(models.Model): 
    # previous fields 
    wheels = models.ForeignKey(Wheels) 

у меня есть, однако, некоторые сомнения по этому поводу:

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

2) Если это правильный дизайн, то я бы хотел, чтобы вы могли добавлять колеса на лету, добавляя велосипед (никогда не добавляйте колеса отдельно). Каков наилучший способ сделать это?

Большое спасибо за любую подсказку/ссылку. Я начинаю с django ...

Answer 1

1. Этот дизайн выглядит хорошо для меня - это хорошая идея, чтобы сохранить отдельные объекты в отдельных таблицах (в данном случае компоненты, которые составляют велосипед - особенно, так как они могут быть проданы отдельно, и велосипеды могут быть настроены с различными частями)

2. Я думаю, что простой запрограммированный класс наследуется от класса велосипеда должен сделать трюк:

   class BicycleFrame(models.Model): 
       brand = models.ForeignKey(Brand) 
       model = models.CharField(max_length=100) 
   
   # class BicycleWheels, BicyclePedals etc.. 
   
   class Bicycle(models.Model): 
       frame = models.ForeignKey(BicycleFrame) 
       wheels = models.ForeignKey(BicycleWheels) 
       pedals = models.ForeignKey(BicyclePedals) 
       # etc ... 
   
   class PresetBicycle(Bicycle): 
       pass 
   
   class PurchaseableMixin(models.Model): 
       user_id = models.ForeignKey(Customer) 
       def purchase(self): 
        # ... call this in the form handler to save this 
        # instance of a bike in the database and maybe 
        # email the customer to inform them of their purchase etc.. 
       class Meta: 
        abstract = True 
   
   class PurchasedBicycle(Bicycle, PurchaseableMixin): 
       pass 
   

..то вы можете создать PresetBicycle в своей области администрирования, а затем в представлении, которое вы показываете клиентам, вы можете отображать PresetBicycle по умолчанию, а также предоставить форму для его покупки, которая автоматически заполняется деталями для PresetBicycle и создает экземпляр Приобретенный велосипед при представлении (структура JS, такая как ReactJS и Backbone, или Angular, может быть лучше всего подходит для просмотра клиентом).

Надеюсь, это поможет!

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

P.P.S Также не то, что я изменил поле бренда, чтобы быть ForeignKey, так как вы можете позже хотите фильтровать на бренд ..

Answer 2

Я сомневаюсь, что (в реальной жизни) у вас действительно будут отношения «один к одному» между велосипедом и колесами - более одной модели велосипеда наверняка будут использовать те же колеса.

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

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

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