Django:sqlite 用于开发,mysql 用于产品?

发布于 2024-08-22 04:27:21 字数 1432 浏览 10 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

定格我的天空 2024-08-29 04:27:21

我强烈建议在生产中和开发中以及其间的所有阶段使用相同的数据库后端。 Django 会抽象数据库的内容,但是不同的环境会让你面临可怕的国际化、配置问题和令人讨厌的微小不一致,这些不一致甚至在你将其推送到上线之前都不会出现。

就我个人而言,我会坚持使用 mysql,但我从来没有使用过 postgres :)

I'd highly recommend using the same database backend in production as in development, and all stages in between. Django will abstract the database stuff, but having different environments will leave you open to horrible internationalisation, configuration issues, and nasty tiny inconsistencies that won't even show up until you push it live.

Personally, I'd stick to mysql, but I never got on with postgres :)

剩余の解释 2024-08-29 04:27:21

我支持以前的所有答案,添加一些明确的原因:

  • 当您尝试存储比字段宽度更长的字符串时,MySQL会发出警告异常 - 您不会在SQLite中得到它们,因此不仅您的字符串在开发和生产之间会有所不同,而且
  • 两个后端的程序行为错误也不同——我记得有一次我尝试过用于开发的 SQLite 和用于生产的 MySQL,但结果发现我在 MySQL 后端发现了一个 SQLite 后端中不存在的错误。所以我提交了一张票并切换到 MySQL 进行测试:-)

你甚至可以尝试在速度方面与 SQLite 竞争,看看我对其他问题的回答:

提高 Django 中 MySQL 表创建的速度?

I second all previous answers, adding some explicit reasons:

  • MySQL issues Warning exception when you try to store string longer that field width - you won't get them in SQLite, so not only you're string will be different between dev and production, but also program behaviour
  • bugs in both backends are different - I remember that once I tried SQLite for dev and MySQL for production, but it turned out that I discovered a bug in MySQL backend which was not present in SQLite one. So I filed a ticket for it and switched to MySQL for testing :-)

And you can even try to compete with SQLite in terms of speed, take a look at my answer for other question:

Increase speed for MySQL table creation in Django?

巴黎夜雨 2024-08-29 04:27:21

你为什么要这么做?

  • SQLite 尚无存储过程支持。
  • SQLite 是无类型。运行 MySQL 时,您可能会遇到很多类型转换问题。
  • 另外 SQLite 还不支持 RIGHT join。

Why would you want to do that?

  • SQLite has no stored procedure support yet.
  • SQLite is typeless. You can end up with a lot of typecast problems when running MySQL.
  • Also SQLite doesn't support RIGHT join yet.
夏末染殇 2024-08-29 04:27:21

在所有环境中使用相同的数据库。

尽管 ORM 试图抽象数据库之间的差异,但总会有某些功能根据数据库的不同而表现不同。数据库可移植性完全是一个神话。

另外,针对您在生产中永远不会使用的代码路径进行测试和开发似乎非常疯狂,不是吗?

Use the same database in all environments.

As much as the ORM tries to abstract the differences between databases, there will always be certain features that behave differently based on the database. Database portability is a complete myth.

Plus, it seems pretty insane to test and develop against code paths that you will never use in production, doesn't it?

爱已欠费 2024-08-29 04:27:21

简而言之,不;除非你想不必要地加倍开发时间。

In short, no; unless you want to unnecessarily double development time.

夏夜暖风 2024-08-29 04:27:21

刚刚从 sqlite 开始犯了这个重大错误,当我尝试使用 mysql 在生产服务器上部署时,事情并没有像我预期的那样顺利。我尝试使用各种开关转储数据/加载数据,但不知怎的,不断出现一个又一个的错误。帮自己一个大忙,使用相同的数据库进行生产和开发。

Just made this major mistake starting off with sqlite and when i try to deploy on production server with mysql, things didn't work as smooth as i expected. I tried dumpdata/loaddata with various switches but somehow keep getting errors thrown one after another. Do yourself a big favor and use the same db for both production and development.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文