我是Django的新手(以及一般的数据库),我不知道如何构建以下内容。我将为我的网站提供的数据来源是:
如果我将数据存储在普通文件中,我只需要为上述每个文件存储一个文件。在Django中,理想情况下(我认为)我会为这些中的每一个都有一个单独的数据库,但显然还有多个数据库支持不适用于Django。我担心(不必要地?)将所有内容保存在一个数据库中有两个原因:
如果我在其中一个部分搞砸了,我不想搞砸剩下的数据。
当我在其中一个部分工作时,我希望能够轻松改变模型。因为我已经知道syncdb
实际上没有同步数据库,所以我决定在弄乱模型时最简单的事情是简单地擦除数据库并重新开始。再一次,我担心弄乱其他部分。我看了south,在应用程序的计划阶段看起来比它的价值更麻烦(但我会在以后有实际有价值的数据时重新考虑)。
部分问题在于我不太习惯以二进制格式保存数据。我习惯于文本,所以我可以很容易地对它进行区分,在编辑器中进行修改等,而无需通过一些神奇的数据库界面(顺便说一句,我使用的是postgresql)。
我的恐惧没有根据吗?人们通常如何处理这个问题?
答案 0 :(得分:9)
对于它的价值,我完全理解你的挫败感,因为我在开始时经历了一个非常相似的思考过程。不幸的是,除了熟悉你将要使用的工具之外,你无能为力(无论如何都很容易)。
首先,您不需要多个数据库来处理您正在做的事情 - 一个人会做。每个应用程序将在数据库中创建自己的表,这些表在某种程度上彼此隔离。正如czarchaic所提到的,如果您更改模型,可以python manage.py reset app_name
重置其中一个。但是,你会丢失这些数据。
要以相对容易使用的格式获取数据,您可以使用命令python manage.py dumpdata > file_name.json
,然后稍后重新加载python manage.py loaddata file_name.json
。您可以将其用于备份,本地测试数据或作为穷人的迁移(提示:南方会更容易)。
另一种选择是将NoSQL数据库用于您认为需要额外灵活性的任何数据。请记住,Django目前不支持任何这些。这意味着没有没有管理员支持或ModelForms。当然,拥有一个模型可能变得没必要。
答案 1 :(得分:4)
简而言之,你的恐惧是没有根据的。您应该按项目“组织”您的数据库以使用Django术语。每个应用程序中的每个模型都有自己的表,但它们都将位于同一个数据库中。由于各种原因,将它们放在单独的数据库中并不是一个好主意,最大的原因是您无法跨数据库进行查询。
虽然我同意南方可能对您的初始设计/开发阶段有点沉重,但对于任何类似于测试版的东西都应该认真考虑,并且在生产中绝对必要。
如果您要在开发过程中弄乱您的模型,最好的办法是在运行同步后使用夹具快速加载数据。或者,如果您要更改一堆必需字段,请编写一些快速Python来为您创建虚拟数据。
至于不信任您的数据到二进制文件,一个简单的“pg_dump”将为您提供数据的文本版本。听起来像你正在使用你的应用程序来对付实时生产数据,这是一个错误。您的目标应该是使您的应用程序在假数据或至少生产数据的副本上构建,工作和测试,然后当您确定所有内容都是黄金时,将其迁移到生产环境中。这就像南方这样的东西派上用场,因为您可以自动执行此部署,它将帮助您处理需要进行的任何数据库表/列更改。
我确信所有这些听起来都很痛苦,但所有这些都能够实现自动化并相信我它会让你的生活变得更加轻松。
答案 2 :(得分:4)
我通常只是重置模块
>>> python manage.py reset blog
这会重置INSTALLED_APPS.blog
我不确定这是否能解决你的问题,但它比擦除数据库更具破坏性。
答案 3 :(得分:1)
Syncdb应该只用于开发。这就是为什么擦除表并重新开始并不重要,可能将查找数据导出到每次同步时可以导入的json文件中。
当您的网站投入生产时,您还可以完成更多工作。您对模型所做的任何需要在数据库中反映的更改都需要作为SQL发出并在数据库上手动运行。有一个django-admin.py函数可以发出建议的SQL,您可以使用该函数构建一个脚本以在数据库上运行以进行迁移。就像你提到的那样,像South这样的迁移应用程序在这里可能是有益的,但并不是严格需要的。
就您的网站分离而言,将它们作为单独的网站/项目运行。每个项目可以有一个单独的设置文件,允许您运行两个不同的数据库。这与将两个站点作为同一项目中的单独应用程序运行形成对比。如果他们完全分开,他们可能不应该在同一个项目中,除非您需要利用通用代码。