Add or modify the data model can not be careless operation of relevant data will need to consider carefully.

Recommended Django model data related packages:

Model-utils-Django : using its TimeStampedModel
Extensions-Django : using its management command shell_plus , it will automatically load all of the data model has been installed applications

basis

Application of the model has a lot of data split

The number of data model is recommended for each application no more than five. If too many data model of an application, the application means too much to do, need to be split.

Carefully chosen data model inheritance

Django supports three inheritance:

Abstract base class
Multi-table inheritance
Agent Model

Django abstract base class and Python abstract base class is different! They have different purposes and behavior.

Various inheritance advantages and disadvantages:

Inheritance | advantages | disadvantages
-------------------------------------------- ---------------------------------------- | --------- -------------------------------------------------- --------------------------------------------- |
abstract base class: only inherited sub-data model will create a data table | can define a common term in the abstract parent class to reduce duplication of input, and multi-table inheritance without the overhead of additional data tables and join operations | parent can not be used alone
multi-table inheritance: parent and child class is created corresponding to the data table. Implicit between a OneToOneField associated | because each sheet has a data model, you can query each of the parent-child operation. While by parent.child from the parent object directly access child objects | sub-table query, there will be a join operation with all of its parent table. Very not recommend the use of multi-table inheritance!
Agent Model: only created for the original data model data table | can create an alias for the original data model, and add different Python behavior | can not modify the data model item

How to determine what kind of inheritance should use:

If a small amount of overlap (only one or two entries), inheritance is not required, only two data models are defined
If there are more duplicates should reconstruct the code, the same items will be placed into an abstract base class between both
Agent model can sometimes be useful, but it is with the other two models are very different inheritance
Avoid using multi-table inheritance, because of an increase of complexity and improves performance overhead. Can OneToOneField and ForeignKeys instead.

Data model is derived from practice: TimeStampedModel

Increase in the data model created and modified two time stamps is a common term needs. TimeStampedModel a base class can be written as follows:

# core/models.py
from django.db import models

class TimeStampedModel(models.Model):
    """
    An abstract base class model that provides self-
    updating ``created`` and ``modified`` fields.
    """
    created = models.DateTimeField(auto_now_add=True)
    modified = models.DateTimeField(auto_now=True)

    class Meta:
        abstract = True

Then all inherited from the abstract base class data model will have these two:

# flavors/models.py
from django.db import models
from core.models import TimeStampedModel

class Flavor(TimeStampedModel):
    title = models.CharField(max_length=200)

Database Migration

Django built a powerful database modification conduction library called Migrations , namely django.db.migrations .

Creating migrations of recommendations:

Once a new application or data model, you should create the initial django.db.migrations immediately for the new data model. In fact, we only need to use Python manage.py makemigrations will be able to complete the command
To be checked before running of the migration code is generated, particularly when it comes to complicated changes. Use sqlmigrate command to verify the actual use of SQL statements
Use MIGRATION_MODULES configuration item to manage third-party application migration
Do not care about generating a lot of migrations, we can use squashmigrations command them merge

Deployment and management of migrations:

Before deployment, you should first check the migrations can be rolled back.
If the table millions of pieces of data, you should test the magnitude of data on the staging server. Migrations time spent on a real database may be much more than expected!
If you are using MySQL:
- It must be backed up before involving mode changes. MySQL does not modify the model to provide transaction support, it is not possible to roll back
- If possible, before the implementation of the project should be put to modify read-only mode
- The number of forms involving a large number of model changes will be spending a lot of time. Not seconds, not a few minutes, but with hourly!

Django data model design

The database normalization

A data model should not have been included in other saved a data model data.

related resources:

Cache should be conducted before denormalization

Only inverse normalization when absolutely necessary

When to use Null and Blank

Data Item Type | set null = True | = True setting blank
------------------------------------- ---------------------------------------------- | --- -------------------------------------------------- -------------------------------------- |
CharField, TextField, SlugField, EmailField, CommaSeparatedIntegerField, UUIDField | Do not set up this way. Django tradition is to save a null value to an empty string, and NULL or empty value resolution to obtain an empty string | can be set. If you allow the corresponding single table accepts null values.
FileField, ImageField | not so set. Django only from MEDIA_ROOT to the path of the file saved in CharField, and therefore the rules above | can be set up, such as the rule CharField
BooleanField | Do not set up this way. Do not use the Field, with NullBoolField | not so set
IntegerField, FloatField, DecimalField, DurationField etc. | If you are allowed to store NULL in the database, it can be set up | if you allow it to appropriate form components accept null values, can be set up, At the same time we want to set null = True
DateFieldField, DateField, TimeField like | if you allow NULL is stored in the database, it can be arranged such | if you allow the corresponding components to form accept null values, or use auto_now , auto_now_add , it can be set up. Meanwhile = True to set null
ForeignKey, ManyToManyField, OneToOneField | can be set up | can be set up
GenericIPAddressField | can be set up | can be set up
IPAddressField | do not recommend using this type, obsolete in Django 1.7 in | do not recommend using this type

When to use BinaryField

This type Django 1.8 added, used to store raw binary data, or bytes . Unable to filter, exclude, or other SQL operations on the type of item. But it will be useful in the following cases:

Content MessagePack format
Sensor raw data
Compressed data. Such as Sentry saved as BLOB data, but for historical reasons need to be base64 encoded

Binary data string can be large, it will slow down the database. At this time, the content should be stored in a file, and then use FileField to reference.

Never provide file services by BinaryField :

Read and write to the database more slowly than the file system
Your database will become more and more, thereby increasing performance low
At this point need to access files through Django application layer and the database layer of a total of two.

Try to avoid using generic associated models.field.GenericForeignKey

GenericForeignKey will not use the foreign key integrity constraints, the following questions:

Due to the lack of an index between models, which will reduce the query speed
Data tables may reference a record that does not exist, there is the risk of damage data

The advantages are: the absence of integrity constraints, a data item can be associated with different types of records. Mostly used in voting, tagging, ratings in.

You can use ForeignKey and ManyToMany to achieve GenericForeignKey function, which is to ensure the integrity of the data, but also enhance the performance.

therefore,

Try to avoid using generic association and GenericForeignKey
If you need general whether the associated words, try to be resolved by adjusting the data model design or use a new PostgreSQL items
If the non unavailable, it is best to use an existing third-party applications

PostgreSQL particular item: When to Use Null and Blank

Data Item Type | set null = True | = True setting blank
------------------------------------- ---------------------- | --------------------------- ---------- |
ArrayField | can set up | can be set
HStoreField | You can set | can set
IntegerRangeField, BigIntegerRangeField and FloatRangeField | can be set. If you want to store in a database NULL | can be set. If you are allowed to form the corresponding assembly receiving null values. Meanwhile = True to set null
DatatimeRangeField and DateRangeField | above | Ibid.

Data model _meta API

_meta internal use only before Django 1.8. The ready-made interfaces have been disclosed.

_meta uses:

Gets the items in the list of data model
Acquire data of class (or its inheritance chain or other information derived) specific item
Make sure you can get the way this information is used will not change in future versions of Django

Example of use:

Django introspection tool to create a data model
Create a custom form library
Admin and create a similar tool to edit or interact with the data in the data model Django
Create a visualization or analysis library, such as analyzing information in order to "foo" at the beginning of term

Data Model Manager

Data Model Manager for limiting a data model class for all possible data records. Django data models for each class provides a default manager.

We can define your own data model management, such as:

from django.db import models
from django.utils import timezone

class PublishedManager(models.Manager):

    use_for_related_fields = True

    def published(self, **kwargs):
        return self.filter(pub_date__lte=timezone.now(), **kwargs)


class FlavorReview(models.Model):
    review = models.CharField(max_length=255)
    pub_date = models.DateTimeField()

    # add our custom model manager
    objects = PublishedManager()

At this point, we would like to find out if all of the number of comments, and then find out the number of comments published, you can do this:

>>> from reviews.models import FlavorReview
>>> FlavorReview.objects.count()
35
>>> FlavorReview.objects.published().count()
31

For the default manager to replace data model, to be especially careful:

First, the use of the data model inheritance, a subclass of the abstract base class receives its parent data model manager, but use a subclass of multi-table inheritance was not
Secondly, the data model manager first applied to the data model classes will be treated as the default manager. This query results and regular Python patterns vary greatly, so will return with the expected difference

Thus, should the objects = models.Manager () placed before any custom data model manager.

Fat understand the data model

fat models concept are: Do the related code data and templates dispersed view, should these methods logic is encapsulated in the data model, class methods, properties even Manager. In this way, all views and tasks can reuse code.

The disadvantage of this approach: the amount of code data model will make more and more, making it difficult to maintain and understand.

Thus, when the data model code amount becomes large complex, it should be associated in the repeated code independent Model Behavior or Helper Functions in.

Behaviors data model, also known as Mixins

Behaviors of the data model by using the concept of a combination Mixins to pursue and packaging.

Related Resources: Use even to reduce the duplication of code

Stateless Helper Functions

These centralized logic functions on the tool, it is separated, thereby making it easier to test. Disadvantages are: These functions are stateless because it needs to pass all parameters.

References: Two Scoops of the Django: Best Practices for the Django 1.8

Two Scoops Django recommended best practices data model