Two Scoops of Django 1.11 章节2.1简译

Posted 2021-05-01 学习是为了更好的躺赢

2.1 在任何地方都要使用同一个数据库引擎

      一个常见的坑就是使用SQLite3作为本地开发数据库，使用PostgreSQL（或mysql）作为产品数据库。这个坑不仅仅适用于SQLite3/PostgreSQL，当你使用任意两个不同的数据库还期待他们的行为一直时都会遇到这个坑。

      这里有一些我们遇到的开发者在使用不同数据库开发时遇到的问题：

2.1.1 你无法在本地检查生产数据的精确副本

     当你的产品数据库和本地开发数据库不一样时，你不能精确复制你的产品数据库用来本地检查数据。

      当然，你可以从产品中使用SQL转储（SQL dump）并将其导入到本地数据库中，但这并不意味着在导出和导入之后有一个精确的副本。

2.1.2 不同的数据库有着不同的字段类型和字段参数

      记住，不同的数据库处理字段类型数据的方式不相同。Django ORM试图适应各数据库间的区别，但它所能做的只有这么多。

      举个例子，一些人使用SQLite3用于本地开发，PostgreSQL用于产品开发。想一想，DjangoORM使得不用数据库之间无需考虑他们之间的差异。最后他们会出现问题，因为SQLite3是动态的，弱类型会转换成强类型。

      是的，Django ORM的特性就是让允许SQLite3这种弱类型代码受强类型行为的影响，但form和model模块编译时捕捉不到错误（甚至使用测试也捕捉不到），直到你的产品运行起来才会发现问题。举个例子，你可能会在本地保存一个很长很长的字符串，因为SQLite3不关心字符串长度。而在产品中，PostgreSQL或MySQL会抛出你在本地从未见过的长度限制错误，你会花很长一段时间去反复解决这个问题，除非你在本地使用同样的数据库。

      使用不用数据库遇到的大多数问题在你的项目运行在强类型数据库（例如PostgreSQL和MySQL）前通常无法被发现。当这些类型bug出现时，你最终会打自己的脸并快速的将本地数据库设置为正确的数据库。

TIP：Django+PostgreSQL模型

就我们所知，大多数Django开发人员喜欢使用PostgreSQL部署所有环境：开发、筹划、QA和生产。       根据你的操作系统使用下面的指南： ® Mac: Download the one-click Mac installer at postgresapp.com ® Windows: Download the one-click Windows installer at      postgresql.org/download/windows/ ® Linux: Install via your package manager, or follow the instructions  at postgresql.org/download/linux/

 

2.1.3 Fixtures 不是一个万能的解决方法

      你可能会觉得奇怪，为什么不能简单的使用fixtures来提取本地数据库和产品数据库之间的不同呢？

      嗯，fixtures是非常强大的创造简单硬编码测试数据包。有时，你需要在开发过程中，特别是在项目的早期阶段，用虚假的测试数据预先填充数据库。

      在非数据库方式中，fixtures不是将大型数据集从一个数据库迁移到另一个数据库的可靠工具。他们根本不想用那种方式。不要错误的认为fixtures创建基本数据的能力（dumpdata /loaddata）可以有能力成为产品数据库之间的数据迁移工具。

 

WARNING：不要在Django产品中使用SQLite3

对于任何大于一个用户或需要轻量并发的web项目，使用SQLite3都会是一场噩梦。用最简单的话来说，使用SQLite3不可能创造出好的产品。这是我们亲身经历，也是从其他人那里听到的可怕经历。       当从SQLite3导出数据到任意具有并发性的数据库（如PostgreSQL）时出现的错误是很复杂且很难解决的。       当我们注意到有一些文章是提倡使用SQLite3开发项目，事实是确实有一小部分人使用SQLite3能避免特定的边缘问题，但这并不是我们在Django产品中使用它的理由。