Design of a database for Django development notes

In the background with Django development, you can experience the convenience of development, for a project, the first and foremost is the database design, then the Django database design is mainly the following steps:

1, demand analysis, this idea needless to say, and I also deeply appreciate the lack of prototype when the development of the difficulties, each time the requirement changes will bring the background data and the corresponding interface changes. Time consuming and energetic

2. With the need, the start of the database design, in Django, does not need to directly manipulate the database, and the use of inherited Modesl. Model class, define your own models in the class, and then use Python manage.py syncdb to see the tables in the database (first you have to set up the connection to the database in Settings)

3. The main point is the user's definition problem, I used the older way, using the profile extension, and did not adopt the way of inheriting abstract user class.

The user's model Django has helped us integrate, and all we have to do is extend our own data on our own user system, extending the following methods:

class UserProfile (models. Model):    #  account additional information    user = models. Onetoonefield (user,unique=True)    # define some of your own additional information, such as gender, etc.

It's a one-to-one approach, and it's easy to use, such as using User.objects.get to get a user and then directly accessing User.userprofile. Property, UserProfile is the name of the extension table that you define ( Older versions prior to Django1.5 use the user's Get_profile function, but are officially recommended for class access in the new version)

The user expands here, and we can also use the Django Auth system without needing to pay attention to details like cookies.

Issues that are noted during database usage:

1, create the user must use User.objects.create_user officially provided function, otherwise auth authentication system cannot pass, and in this way create user, password is encrypted, so the official API is recommended when the official API, Otherwise, some modules of the framework may not be available.

2. The database encoding must be used Utf-8

3. The official own database abstraction layer because of its universality, so it is more cumbersome to use directly, such as changing user data must simultaneously operate both user and userprofile two tables, so at this time we can write another layer of interface on the official abstraction layer ( Called the Django-brought database abstraction layer, which makes the database interface more attuned to business logic (which is equivalent to isolating the Django Database abstraction layer and making it easier to use).

4. Front and rear communication is to do the foreground and backstage interaction of the big problem, although Django comes with the form system, but for the front desk, use up or not used to, so I gave up the Django form system, front and back communication using pure variables, due to some of the data too much, And the context passing through the template rendering is also cumbersome, so on the interface that you write (3 mentions the interface of the Django Abstraction layer) needs the function, and then use the Ajax way to return XML information to the foreground, but also unified use of XML communication, but because the django {{} The label mode is very handy for some variables, so it's a mix.