有人对Web应用程序的数据库设计有任何提示/建议吗？当/如果我正在处理的应用程序起飞并开始大量使用时，这种东西将来可以为我节省很多时间/精力。

更具体地说，该应用程序是一种策略游戏(基于浏览器，仅是文本)，主要涉及玩家发出"订单"的命令，这些命令将存储在数据库中并在以后进行处理，结果也将存储在数据库中(历史记录的"订单"，相应的结果可能会变得相当大)。

编辑以添加更多详细信息(根据要求)：

平台：Django

数据库引擎：我正在考虑使用MySQL(除非使用另一个有很大的优势)

模式：我现在只拥有一些Django模型，这里有太多细节。而且，如果我开始发布架构，那么它变得太具体了，我在寻找一般性提示。例如，考虑我发出"订单"，稍后将对其进行处理，并返回必须存储以显示某种"历史记录"的结果。在这种情况下，最好是为"历史记录"创建一个单独的表，或者仅将"订单"和结果进行汇总的表？我想我可以缓存"历史记录"表，但是这将占用数据库中更多的空间以及更多的数据库操作，因为我将不得不不断创建新行，而不仅仅是在聚合表中对其进行更改。

解决方案

回答

数据库规范化以及对索引的充分考虑是我们不容错过的两件事。尤其是考虑游戏时，SELECT发生的频率要比UPDATE发生的频率高得多。

从长远来看，我们还应该看一下memcached，因为只要有多个用户，数据库查询就会成为瓶颈。

回答

通常，我们可能已经谈到了为实现高可伸缩性和高性能而设计的更大问题。

本质上，对于数据库设计，我将遵循良好的做法，例如向希望经常使用的数据添加外键和索引，通过将数据拆分为较小的表来规范化数据，并确定哪些数据将被频繁读取以及哪些数据将被频繁读取。写得频繁而乐观。

对于高性能Web应用程序而言，比数据库设计更为重要的是，我们可以有效地在客户端级别(通过HTML页面缓存)和服务器级别(通过缓存的数据)或者提供静态文件(代替动态文件)中有效地使用缓存。

缓存的妙处在于可以根据需要添加它，这样当应用程序启动时，我们就可以相应地进行开发。

就历史数据而言，这是一件很棒的事情，因为我们不希望它经常更改。如果我们希望从数据中生成定期且相当密集的报告，则最好将这些数据放入另一个数据库中，以免Web应用程序在运行时停止运行。

当然，除非我们认为应用程序可以保证，否则这种优化实际上是没有必要的。

回答

为什么不发布现在的架构？没有一个详细的信息将要有用地回答这个问题，而这个细节没有我们将要使用的平台和数据库以及我们建议的表结构的详细信息...

回答

如果发现自己在一个查询中加入了6个以上的表来检索经常被点击的报告类型网页的数据，则应该对表进行非规范化。另外，如果我们使用Hibernate或者ActiveRecord之类的ORM库，请确保花一些时间在它们生成的默认映射以及最终生成的sql上。当我们一次往返数据库时可以达到相同的结果时，它们往往会对数据库保持沉默。