我正在慢慢学习Django试图编写一个应用程序来替换我们现在拥有的复杂的PHP混乱。最后我们需要的是非常简单，但我试图围绕最好的方式（或“django方式”）做事情。这就是我们的工作：
我们管理比赛（我称之为事件），并为他们进行在线注册和付款。这基本上意味着用户访问URL，在表单中填写一些个人信息，然后他们在数据库中并发送到PayPal进行付款。
因此，使用当前系统，某些软件会创建一个“种族”表单，其中包含我想要的表单字段，然后在幕后创建一个DB表，其中包含种族名称。该表包含所有注册（显然每个表单字段都有一列，另外还有一些用于幕后处理的附加内容）。目前我只是在每年的比赛中重新创建表单，但我正在考虑使用Django我将更清洁并保存重复的工作并在Django土地中使用相同的“形式”或“模型”并且只是有一些方法将该数据存档到另一个数据库。
无论如何，这里我需要一些建议：Django似乎每个模型都有一个数据库表？所以我想的是我有一个“种族”模型，其中包含一些关于种族的一般信息，包括一些问题，这些问题将决定我的其他模型中显示哪些表格字段（例如，如果比赛需要付款，我们'将为PayPal提供一些额外的字段和逻辑。所有比赛都将在一个数据库表中，但这可能在这里很好......不会 很多。
然而，我当时认为会有一个“注册”模型实际上包含所有这些表单字段，并且将落后于人们填写的实际注册表单。但我认为这意味着每场比赛（通过一个外键）的所有注册都将在其中...所有这些注册表。也许它不是那么多，但是在一张桌子上为所有比赛进行所有注册似乎是混乱和不洁净的。比赛平均有大约500人，有些可能是几千人。我只是忍受它还是有更好的方法来设计它？
我也在考虑灵活性......有时在过去，我不得不手动将一些数据加载到表格中，以便针对特定种族进行特定表格或批量更改注册。是的，我可以更具体地查询我的问题，但感觉更安全，因为我只能影响一个种族的注册，因为它们是单独的表格。我是否只是将数据库视图创建为某种替代方案？
最后，我只想确保这是一个不会减速或效率太低的好设计，例如，当我需要偶尔进行排序以及每个种族的出口时（这样才会最终需要查询特定的种族ID并让所有为该种族注册的人。
抱歉这么长，我现在正在做django教程，我只是想确定，因为我在脑海里想着这将如何发展，我将会有一个像样的设计。非常感谢！
答案 0 :(得分：1)
Django似乎每个模型都有一个数据库表
实际上你最好再考虑一下：Django＆＃34; Model＆＃34;是一个数据库表的表示。
但我认为这意味着每场比赛的所有注册（通过一个 外键）将在其中......所有人都有一张桌子。也许不是 那么多，但是所有注册都显得凌乱和不洁 对于一张桌子中的所有比赛。
为什么???
比赛平均有大约500人，有些可能是几千人。
SQL数据库旨在处理更多更大的数据集 - 想想数百万行甚至更多。每场比赛2000次注册和每年几场比赛，你不必担心太多。现在，如果你有人参加一个以上的比赛，那么你可以选择三张桌子来做得更好：
具有唯一约束（registration.race_id，registratio.person_id）。
从你的问题我假设你很少知识 - 如果有的话 - 或关系数据库，所以我强烈建议你花一些时间学习正确的关系数据库建模。