有人对 Web 应用程序的数据库设计有任何提示/建议吗?当/如果我正在开发的应用程序启动并开始大量使用时,这种东西可以在将来为我节省大量时间/精力。

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

编辑以添加更多详细信息 (按照要求):

平台:姜戈

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

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

有帮助吗?

解决方案

您可能已经接触过一个更大的问题,即总体上的高可扩展性和性能设计。

本质上,对于您的数据库设计,我将遵循良好的实践,例如向您希望经常使用的数据添加外键和索引,通过将数据拆分为较小的表来规范化数据,并确定哪些数据要经常读取以及哪些数据要被读取。经常编写并优化。

比高性能 Web 应用程序的数据库设计更重要的是,通过 HTML 页面缓存在客户端级别以及通过缓存数据或提供静态文件代替动态文件在服务器级别有效使用缓存。

缓存的好处在于它可以根据需要添加,这样当您的应用程序真正起飞时,您就会相应地发展。

就您的历史数据而言,缓存这是一件很棒的事情,因为您不希望它频繁更改。如果您希望根据数据生成定期且相当密集的报告,那么最好将此数据放入另一个数据库中,以免您的 Web 应用程序在运行时停止。

当然,这种优化确实没有必要,除非您认为您的应用程序需要这样做。

其他提示

数据库规范化, ,以及对索引的充分考虑,是您不能错过的两件事。特别是如果您考虑一款游戏,其中选择发生的频率比更新发生的频率要高得多。

从长远来看,你还应该看看 内存缓存, ,因为只要您有多个用户,数据库查询就可能成为瓶颈。

你为什么不发布你现在拥有的架构?如果没有详细说明您将使用什么平台和数据库以及您建议的表结构,这个问题太广泛了,无法有效回答......

你应该 非规范化 如果您发现自己在一个查询中加入了 6 个以上的表来检索经常点击的报告类型网页的数据,则您的表。另外,如果您使用 Hibernate 或 ActiveRecord 等 ORM 库,请确保花一些时间研究它们生成的默认映射以及最终生成的 sql。当您可以通过数据库的一次往返获得相同的结果时,他们往往会与数据库进行非常频繁的交谈。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top