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