Django 1.11+MySQL汽车广告表：字段选项用单独表还是模型元组？

Hey there! Let’s break down the two common approaches for your Django 1.11 + MySQL car ad database setup, based on the requirements you’ve shared. I’ll walk through each option’s pros, cons, and implementation examples to help you pick the best fit.

Background Recap #

You’re building a car ad table with:

• Core fields: Title, Price, Posted Time
• Feature fields with fixed/standard options: Condition (excellent/very good/good/poor), Fuel Type (gas/diesel), Cylinders (3/4/5/6/8/12), etc.

Option 1: Single Table + Django Choice Fields #

This is the simplest approach—embed all feature options directly as fields in your CarAd model using Django’s built-in choices parameter.

Implementation Example

# models.py
from django.db import models

# Define option choices as constants
CONDITION_CHOICES = [
    ('excellent', 'Excellent'),
    ('very good', 'Very Good'),
    ('good', 'Good'),
    ('poor', 'Poor'),
]

FUEL_TYPE_CHOICES = [
    ('gas', 'Gas'),
    ('diesel', 'Diesel'),
]

CYLINDER_CHOICES = [
    (3, '3'),
    (4, '4'),
    (5, '5'),
    (6, '6'),
    (8, '8'),
    (12, '12'),
]

class CarAd(models.Model):
    title = models.CharField(max_length=200)
    price = models.DecimalField(max_digits=10, decimal_places=2)
    posted_at = models.DateTimeField(auto_now_add=True)
    
    # Feature fields with choices
    condition = models.CharField(max_length=20, choices=CONDITION_CHOICES)
    fuel_type = models.CharField(max_length=20, choices=FUEL_TYPE_CHOICES)
    cylinders = models.IntegerField(choices=CYLINDER_CHOICES)
    
    def __str__(self):
        return self.title

Pros

• Dead simple to build: No extra tables or complex relationships to manage.
• Fast queries: All data lives in one table, so no joins are needed for basic ad lookups.
• Built-in UI support: Django Admin automatically renders dropdown menus for choices fields, and templates can use {{ car_ad.get_condition_display }} to show user-friendly labels instead of raw values.

Cons

• Inflexible options: To add/modify a feature option (e.g., add a "hybrid" fuel type), you’ll need to edit the model and run a database migration.
• Scaling limitations: If you add dozens of feature fields over time, your table will become wide and harder to maintain.
• No extra metadata: You can’t attach additional info to options (e.g., a description for each condition tier) without hacking the model.

Option 2: Normalized Schema with Related Tables #

This approach uses separate tables for feature types and their options, then links them to the CarAd model via foreign keys or many-to-many relationships. It’s more scalable and follows database normalization best practices.

Implementation Example (Per-Feature Tables)

If each feature has distinct properties, create individual tables for each:

# models.py
from django.db import models

class Condition(models.Model):
    slug = models.CharField(max_length=20, unique=True)  # 'excellent'
    display_name = models.CharField(max_length=20)  # 'Excellent'
    description = models.TextField(blank=True)  # Optional extra info

class FuelType(models.Model):
    slug = models.CharField(max_length=20, unique=True)  # 'gas'
    display_name = models.CharField(max_length=20)  # 'Gas'

class CylinderCount(models.Model):
    number = models.IntegerField(unique=True)  # 3, 4, etc.
    display_label = models.CharField(max_length=5)  # '3 Cylinders'

class CarAd(models.Model):
    title = models.CharField(max_length=200)
    price = models.DecimalField(max_digits=10, decimal_places=2)
    posted_at = models.DateTimeField(auto_now_add=True)
    
    # Foreign key relationships to feature tables
    condition = models.ForeignKey(Condition, on_delete=models.PROTECT)
    fuel_type = models.ForeignKey(FuelType, on_delete=models.PROTECT)
    cylinders = models.ForeignKey(CylinderCount, on_delete=models.PROTECT)
    
    def __str__(self):
        return self.title

Pros

• Maximum flexibility: Add/remove feature options via the Django Admin (no code changes or migrations required).
• Extensible metadata: Attach extra details to options (like condition descriptions) without modifying the core CarAd model.
• Clean database design: Avoids redundant data and follows 3NF normalization rules.

Cons

• Slightly slower queries: Basic lookups will require joining multiple tables (though MySQL’s query optimizer minimizes this impact for small datasets).
• More setup work: You’ll need to create and configure extra models, and use select_related/prefetch_related in queries to avoid "N+1" database hits.
• Admin configuration: You’ll need to set up inline editors or custom admin views to manage feature options alongside ads.

Which Option Should You Choose? #

• Go with Option 1 if: Your feature options are static (unlikely to change) and you want a minimal, easy-to-maintain setup. This is perfect for standard car specs that don’t evolve often.
• Go with Option 2 if: You expect to add new features/options over time, need to store metadata for options, or want a scalable, future-proof database design.

For Django 1.11 specifically:

• When using choices in Option 1, remember you can access human-readable labels with get_<field>_display() in templates.
• In Option 2, use on_delete=models.PROTECT for foreign keys to prevent accidental deletion of feature options that are linked to active ads.

内容的提问来源于stack exchange，提问作者Saleh