有人对 Web 应用程序的数据库设计有任何提示/建议吗？当/如果我正在开发的应用程序起飞并开始大量使用时，这种东西可以在未来为我节省大量时间/精力。
更具体地说，该应用程序是一个策略游戏（基于浏览器，仅文本），主要涉及玩家发出“订单”，这些“订单”将存储在数据库中并稍后处理，结果也存储在那里（历史“订单”和相应的结果可能会变得相当大）。
编辑以添加更多详细信息（根据要求）：
平台：Django
数据库引擎：我正在考虑使用 MySQL（除非使用另一个有很大的优势）
架构：我现在只有一些 Django 模型，这里发布的细节太多了。如果我开始发布模式，这会变得过于具体，我正在寻找一般提示。例如，考虑我发出稍后将处理的“订单”并返回我必须存储以显示某种“历史”的结果。在这种情况下，最好为“历史”创建一个单独的表，还是只使用一个汇总“订单”和结果的表？我想我可以缓存“历史”表，但这会占用数据库中的更多空间以及更多的数据库操作，因为我必须不断地创建新行，而不仅仅是在聚合表中更改它们。
您可能已经触及了一个更大的问题，即为一般的高可伸缩性和性能而设计。
本质上，对于您的数据库设计，我会遵循良好的做法，例如将外键和索引添加到您希望经常使用的数据中，通过将数据拆分为较小的表来规范化您的数据，并确定哪些数据将被频繁读取，哪些数据将被经常写和优化。
比高性能 Web 应用程序的数据库设计更重要的是，您在客户端级别通过 HTML 页面缓存和在服务器级别通过缓存数据或提供静态文件代替动态文件来有效使用缓存。
缓存的好处是可以根据需要添加它，这样当您的应用程序起飞时，您就会相应地发展。
就您的历史数据而言，缓存是一件好事，因为您不希望它经常更改。如果您希望从您的数据中生成定期且相当密集的报告，那么最好将此数据放入另一个数据库中，以免您的 Web 应用程序在运行时停止。
当然，这种优化实际上是没有必要的，除非您认为您的应用程序需要这样做。
你为什么不发布你现在拥有的架构？如果没有关于您将使用的平台和数据库以及您提出的表结构的一些细节，这个问题太宽泛了，无法有效地回答......
如果您发现自己在一个查询中加入 6 个以上的表以检索经常被点击的报告类型网页的数据，则应该对表进行非规范化。此外，如果您使用 Hibernate 或 ActiveRecord 等 ORM 库，请确保花一些时间在它们生成的默认映射和最终生成的 sql 上。当您可以通过一次往返数据库获得相同的结果时，他们往往对数据库非常健谈。