用 Django 管理现有数据库

在多数项目中，总有一些几乎一成不变的 CRUD 操做，编写这些代码很无聊，但又是整个系统必不可少的功能之一。咱们在上一个项目中也面临相似的问题，虽然已经实现了一个功能相对完整的管理后台，也尽可能作到了代码复用，但随着项目规模的增加，须要编写的样本代码也不断膨胀，占用了大量开发时间。

面对这种局面，我天然想到了 Django。要知道， Django Admin 几乎就是为这种需求量身定制的。但对于咱们的项目而言，还有几个问题要解决：

• 咱们的数据库使用 SQL Server。Django 默认对此没有很好的支持；
• 数据库结构是由另外一个工具管理的，Django 并无直接修改数据库结构的权限。因*
• 此，咱们不能使用 Django migrate；

出于一样的理由，咱们没法在数据库中建立 Django Admin 内置要求的数据表（包括 auth/session 等）。
下面咱们来解决这些问题。若是你碰到相似状况的话，能够参考本文的作法。

SQL Server 支持

遗憾的是，针对 Django 开发的 SQL Server 适配器虽然有几种，但都比较古老了，对新版的 Django 支持存在问题。通过尝试，咱们选择了 Django-Mssql，虽然功能是可用的，但该库只支持到 Django 1.8，经测试，对 Django 1.11 不兼容，Django 2.x 就更不行了。好在咱们并不须要很新的功能，所以就用 virtualenv 锁定版本了：

Django==1.8
django-mssql==1.8
pywin32==223

  在这里仍是要推荐下我本身建的Python开发学习群：725479218，群里都是学Python开发的，若是你正在学习Python ，小编欢迎你加入,你们都是软件开发党，不按期分享干货（只有Python软件开发相关的），包括我本身整理的一份2018最新的Python进阶资料和高级开发教程，欢迎进阶中和进想深刻Python的小伙伴
django-mssql 是 Windows 版的库，幕后使用了 ADO 为驱动，所以同时还要安装 pywin32。

多数据库

针对第二和第三个问题基本上有两个思路。第一个是经过实现自定义的 Backend 来跳过 Django 内置的、基于数据库的实现。从原理上来说是行得通的，但简单尝试了一下，发现要自定义的部分至关多，工做量太大。总之，这条路不是很可取。

第二个思路是利用 Django 的多数据库支持。既然业务数据库不可由 Django 来管理，那么就再用一个数据库来支持 Django 的基本功能，而 Django 对业务数据库只做查询和更新，不执行 migrate。固然，为了使用多个数据库，咱们须要在配置上多作一些工做。因为使用后台的用户基本上只有公司内部的业务人员，数据量不会大，用服务器级的数据库有牛刀之嫌。处于简便考虑，这里使用默认的 SQLite 做为内置数据库：

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    },
    'mydb': {
        'ENGINE': 'sqlserver_ado',
        'HOST': '127.0.0.1',
        'NAME': '<DB_NAME>',
        'USER': '<DB_USER>',
        'PASSWORD': '<DB_PASSWORD>',
        'OPTIONS': {
            'provider': 'SQLOLEDB',
        }
    }
}

须要说明，Django-mssql 为 provider 选项提供的默认值（按照官方文档应为 SQLCLI10）实测会致使出现“找不到提供程序” 的错误。因为 provider 的设置取决于 ADO 的注册信息，不必定在全部机器上都相同，因此你可能须要本身测试决定哪一个选项可用。

如今咱们配置了两个数据源，但还须要告诉 Django 它们和模型的对照关系。实现这一点能够在语句/实体/全局等多种级别定义。对于咱们的需求而言，对应关系是固定的，逐个模型定义并没有必要，经过全局定义是最简单的。实现这必定义的对象在 Django 的术语中称为数据库路由（Database Router）。首先在 settings.py 中定义类名：

DATABASE_ROUTERS = ['project.db.MyAppRouter']

而后完成类的实现：

class MyAppRouter:
    def db_for_read(self, model, **hints):
        if model._meta.app_label == 'myapp':
            return 'myapp'
        return None

    def db_for_write(self, model, **hints):
        if model._meta.app_label == 'myapp':
            return 'myapp'
        return None

    def allow_relation(self, obj1, obj2, **hints):
        return None

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        return False

数据路由须要按照 Django 的要求实现四个方法。其中主要是读写两个方法，咱们须要根据传来的模型决定匹配到哪一个数据源。 其余两个方法目前意义不大，按照默认的实现便可。

定义模型

配置到此完成，接下来须要建立模型。对于已经存在的数据表，能够用管理命令 inspectdb 反向生成代码，减小一些手工输入的负担。但生成的代码未必彻底符合你的要求，因此仍是应该本身检查一下。对于 SQL Server，若是主键名不是默认的 id，那么 inspectdb 彷佛不会自动识别到它们，因此咱们须要检查一下主键字段有无 primary_key，若是没有的话就加上。

python manage.py inspectdb --database=myapp > myapp\models.py

为了方便调试和辨别记录，通常来讲咱们还要为模型类加上 verbose_name 并重载内置的字符串方法。

class XXModel(models.Model):
    XXId = models.BigIntegerField(primary_key=True)
    ...

    class Meta:
        managed = False
        db_table = 'XXModel'
        verbose_name = '模型名称'
        verbose_name_plural = '模型名称'

    def __str__(self):
        return self.XXField

把模型添加到 admin，对应的后台管理信息就完成了。

admin.site.register(XXModel, XXAdmin)

运行程序

最后，为内置数据库生成必要的表，建立管理员帐户，便可运行程序。如下命令就无需说明了：

$ python manage.py migrate
$ python manage.py createsuperuser
$ python manage.py runserver

总结

咱们第一个版本的后台程序是本身手工编码完成的，用了大概两周的时间。问题在于，每增长一个模型都要手工添加大量样本代码。而改写成 Django 只用了一天时间，包括熟悉相关资料和使用方法，增长一个模型只需花几分钟。这也是为何不少了解 Django 的开发者转移到其余平台之后，会寻找相似的项目。就我了解的范围，Spring Boo 和 Django 在概念上比较相似，但 Boo 主要走的是代码生成的路线，复杂度更高，理论上灵活性也应该更好一些（我没有深度研究过）。Nodejs 社区有 Keystone.js 和 Sails.js，不过前者专门针对 MongoDB，后者支持多种数据库后端，但风闻最近有中止开发的迹象。.Net 社区之前有一个 DynamicData，如今彷佛也没了下文。发展多年的 Django 也应该算是同类产品中最成熟、生态也最为完整的产品了。

Django 潜在的问题在于不够现代化的界面，以及深度定制较为困难。不过对于咱们的后台应用来讲，这些都是能够接受的代价。