django db schema - 创建不同类型的任务，每个任务都有不同的字段
对于以下场景，使用 django 的最佳数据库设计是什么：
我在数据库中有一个计算机列表。我想添加一个由计算机执行的任务。有不同的任务，每个任务都有不同的领域。例如，一个可能是“安装程序”，它具有程序表的外键，其中条目包含有关如何安装程序的信息。或者它可能类似于“更改设置”，包含设置表的外键。
我正在考虑使用带有（名称，描述）的任务类型，但为了使上述工作正常进行，每个任务都必须具有程序和设置的外键，即使任务不使用其中任何一个。这似乎不是最好的...还有其他方法吗？
What's the best DB design, using django, for the following scenario:
I have a list of computers in the database. I want to add a task to be executed by a computer. There are different tasks, each with different fields. For example, one might be "install program", which has a ForeignKey to the Program table, where the entries contain info on how to install the program. Or it might be like "change setting", containing ForeignKey to a Setting table.
I was thinking of having a TaskType with (name, description), but to make the above work, each one would have to have foreign key to Program and Setting, even if the task doesn't use either. that seems not the best... is there another way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如上所述，您的概念架构涉及以下谓词：
你也出现了一个约束，你需要判断它有多大：
有些人可能建议自然的 Django 解决方案是使用 模型继承 表示基本“任务”模型，具有两个子类- “安装任务”和“设置任务”。然后你要么携带
“computer”作为基类的属性，或者有另一个模型“ComputerTask”等。
使用模型继承会带来一些好处，包括 (1) 在创建 ChangeTask 的同时获得创建基本任务的一些支持，以及 (2) 鼓励但不强制维护约束。
但是，根据我的经验，模型继承存在概念问题，您可能会遇到令人惊讶和不需要的行为，例如更新任务。在这种情况下，我可以简单地将任务 1:1 与 InstallTask 放在一起，将 1:1 与SettingTask 放在一起。这样其实更加灵活。
As described, your conceptual schema involves the following predicates:
You also appear to one constraint, you need to judge how significant it is:
Some might suggest the natural Django solution would be to use model inheritance to represent a base "Task" model, with two subclasses - "InstallTask" and "SettingTask". You then either carry the
"computer" as an attribute of the base class, or alternatively have another model "ComputerTask" or such.
Using model inheritance would afford some benefits, including (1) getting some support for creating the base Task at the same time as you create, say, the ChangeTask, and (2) encouraging, but not enforcing, maintenance of the constraint.
However, in my experience, there are conceptual problems with model inheritance, and you may encounter surprising and unwanted behavior, for example, updating tasks. In this case, I might simply place Task 1:1 with InstallTask and 1:1 with SettingTask. This is actually more flexible.
不确定您的确切问题（没有足够的数据），所以我的答案有点抽象（或高水平）:)
恕我直言，看起来您可能对 使用内容类型的通用关系。
使用此功能将为您提供从一种模式链接到任何其他模式的选项，
所以你可以有不同的对象作为参考。
Not sure about your exact issue (not enough data) so my answer will be little abstract (or high level) :)
IMHO, looks like you may be interested in the generic relations that are working with content types.
Using this feature will give you an option to link from one mode to any other,
so you can have different Objects as the reference.