问在Django中，null=True和blank=True有什么区别？

EN

models.DateTimeField(blank=True) # raises IntegrityError if blank

models.DateTimeField(null=True) # NULL allowed, but must be filled out in a form

models.CharField(blank=True) # No problem, blank is stored as ''

models.CharField(null=True) # NULL allowed, but will never be set as NULL

class Test(models.Model):
    charNull        = models.CharField(max_length=10, null=True)
    charBlank       = models.CharField(max_length=10, blank=True)
    charNullBlank   = models.CharField(max_length=10, null=True, blank=True)

    intNull         = models.IntegerField(null=True)
    intBlank        = models.IntegerField(blank=True)
    intNullBlank    = models.IntegerField(null=True, blank=True)

    dateNull        = models.DateTimeField(null=True)
    dateBlank       = models.DateTimeField(blank=True)
    dateNullBlank   = models.DateTimeField(null=True, blank=True)        

CREATE TABLE Test (
  id              serial                    NOT NULL,

  "charNull"      character varying(10),
  "charBlank"     character varying(10)     NOT NULL,
  "charNullBlank" character varying(10),

  "intNull"       integer,
  "intBlank"      integer                   NOT NULL,
  "intNullBlank"  integer,

  "dateNull"      timestamp with time zone,
  "dateBlank"     timestamp with time zone  NOT NULL,
  "dateNullBlank" timestamp with time zone,
  CONSTRAINT Test_pkey PRIMARY KEY (id)
)

CREATE TABLE Test (
     `id`            INT(11)     NOT  NULL    AUTO_INCREMENT,

     `charNull`      VARCHAR(10) NULL DEFAULT NULL,
     `charBlank`     VARCHAR(10) NOT  NULL,
     `charNullBlank` VARCHAR(10) NULL DEFAULT NULL,

     `intNull`       INT(11)     NULL DEFAULT NULL,
     `intBlank`      INT(11)     NOT  NULL,
     `intNullBlank`  INT(11)     NULL DEFAULT NULL,

     `dateNull`      DATETIME    NULL DEFAULT NULL,
     `dateBlank`     DATETIME    NOT  NULL,
     `dateNullBlank` DATETIME    NULL DEFAULT NULL
)

- The most common use is for optional string-based fields. As [noted in the documentation](https://docs.djangoproject.com/en/dev/ref/models/fields/#null), the Django idiom is to use the empty string to indicate a missing value. If `NULL` was also allowed you would end up with two different ways to indicate a missing value. (If the field is also `unique`, though, you'll have to use `null=True` to prevent multiple empty strings from failing the uniqueness check.)

- Another common situation is that you want to calculate one field automatically based on the value of another (in your `save()` method, say). You don't want the user to provide the value in a form (hence `blank=True`), but you do want the database to enforce that a value is always provided (`null=False`).

- Another use is when you want to indicate that a `ManyToManyField` is optional. Because this field is implemented as a separate table rather than a database column, [`null` is meaningless](https://stackoverflow.com/a/18244527/2395796). The value of `blank` will still affect forms, though, controlling whether or not validation will succeed when there are no relations.

- It's perfectly reasonable to require your users to always include a value even if it's not actually required by your business logic. After all, forms are only one way of adding and editing data. You may have code that is generating data that doesn't need the same stringent validation you want to require of a human editor.

- Another use case that I've seen is when you have a `ForeignKey` for which you don't wish to allow [cascade deletion](https://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.ForeignKey.on_delete). That is, in normal use the relation should always be there (`blank=False`), but if the thing it points to happens to be deleted, you don't want this object to be deleted too. In that case you can use `null=True` and `on_delete=models.SET_NULL` to implement a simple kind of [soft deletion](https://stackoverflow.com/questions/378331/physical-vs-logical-soft-delete-of-database-record).