Quick question: is it a good idea to use sqlite while developing a Django project, and use MySQL on the production server?
快速提问：在开发Django项目时使用sqlite并在生产服务器上使用MySQL是个好主意吗？
6 个解决方案
#1
20
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.
我强烈建议在开发中使用与生成相同的数据库后端，以及介于两者之间的所有阶段。 Django将抽象数据库的东西，但是拥有不同的环境会让你容易受到可怕的国际化，配置问题和令人讨厌的微小不一致的影响，直到你推送它们才会出现。
Personally, I'd stick to mysql, but I never got on with postgres :)
就个人而言，我坚持使用mysql，但我从来没有使用过postgres :)
#2
7
Why would you want to do that?
你为什么想这么做？
- SQLite has no stored procedure support yet.
- SQLite还没有存储过程支持。
- SQLite is typeless. You can end up with a lot of typecast problems when running MySQL.
- SQLite是无类型的。运行MySQL时，最终可能会出现很多类型转换问题。
- Also SQLite doesn't support RIGHT join yet.
- SQLite也不支持RIGHT join。
#3
7
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
- 当你尝试将字符串的字符串长度存储时，MySQL会发出警告异常 - 你不会在SQLite中获取它们，因此不仅你的字符串在开发和生产之间会有所不同，而且程序行为也是如此
- 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 :-)
- 两个后端中的错误是不同的 - 我记得曾经我尝试使用SQLite for dev和MySQL进行生产，但事实证明我在MySQL后端发现了一个在SQLite中没有的错误。所以我为它提交了一张票并转到MySQL进行测试:-)
And you can even try to compete with SQLite in terms of speed, take a look at my answer for other question:
你甚至可以尝试在速度方面与SQLite竞争，看看我对其他问题的回答：
Increase speed for MySQL table creation in Django?
提高Django中MySQL表创建的速度？
#4
5
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.
尽管ORM试图抽象数据库之间的差异，但总会有某些功能在数据库的基础上表现不同。数据库可移植性是一个完整的神话。
Plus, it seems pretty insane to test and develop against code paths that you will never use in production, doesn't it?
另外，对于您将永远不会在生产中使用的代码路径进行测试和开发似乎非常疯狂，不是吗？
#5
3
In short, no; unless you want to unnecessarily double development time.
简而言之，没有;除非你想不必要地加倍开发时间。
#6
2
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.
刚刚开始使用sqlite时出现了这个重大错误，当我尝试使用mysql在生产服务器上进行部署时，事情并没有像我预期的那样顺利。我尝试使用各种交换机的dumpdata / loaddata但不知何故一个接一个地抛出错误。做一个大忙，并为生产和开发使用相同的数据库。
#1
20
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.
我强烈建议在开发中使用与生成相同的数据库后端，以及介于两者之间的所有阶段。 Django将抽象数据库的东西，但是拥有不同的环境会让你容易受到可怕的国际化，配置问题和令人讨厌的微小不一致的影响，直到你推送它们才会出现。
Personally, I'd stick to mysql, but I never got on with postgres :)
就个人而言，我坚持使用mysql，但我从来没有使用过postgres :)
#2
7
Why would you want to do that?
你为什么想这么做？
- SQLite has no stored procedure support yet.
- SQLite还没有存储过程支持。
- SQLite is typeless. You can end up with a lot of typecast problems when running MySQL.
- SQLite是无类型的。运行MySQL时，最终可能会出现很多类型转换问题。
- Also SQLite doesn't support RIGHT join yet.
- SQLite也不支持RIGHT join。
#3
7
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
- 当你尝试将字符串的字符串长度存储时，MySQL会发出警告异常 - 你不会在SQLite中获取它们，因此不仅你的字符串在开发和生产之间会有所不同，而且程序行为也是如此
- 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 :-)
- 两个后端中的错误是不同的 - 我记得曾经我尝试使用SQLite for dev和MySQL进行生产，但事实证明我在MySQL后端发现了一个在SQLite中没有的错误。所以我为它提交了一张票并转到MySQL进行测试:-)
And you can even try to compete with SQLite in terms of speed, take a look at my answer for other question:
你甚至可以尝试在速度方面与SQLite竞争，看看我对其他问题的回答：
Increase speed for MySQL table creation in Django?
提高Django中MySQL表创建的速度？
#4
5
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.
尽管ORM试图抽象数据库之间的差异，但总会有某些功能在数据库的基础上表现不同。数据库可移植性是一个完整的神话。
Plus, it seems pretty insane to test and develop against code paths that you will never use in production, doesn't it?
另外，对于您将永远不会在生产中使用的代码路径进行测试和开发似乎非常疯狂，不是吗？
#5
3
In short, no; unless you want to unnecessarily double development time.
简而言之，没有;除非你想不必要地加倍开发时间。
#6
2
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.
刚刚开始使用sqlite时出现了这个重大错误，当我尝试使用mysql在生产服务器上进行部署时，事情并没有像我预期的那样顺利。我尝试使用各种交换机的dumpdata / loaddata但不知何故一个接一个地抛出错误。做一个大忙，并为生产和开发使用相同的数据库。