在 mysql 中布局股票表的最佳原因是什么？

Question

我正在构建一个比传统库存系统更少的系统来为浏览器/手机游戏提供动力。基本主体是building 具有某些resources 的stock。这些buildings 的每小时产量减少了每座建筑物的进口并产生出口。这些作品基于structure 作为building 的类型以及建筑物的水平和容量。

我的难题是如何以可扩展的方式布置这些库存表。我能够构建表格，以便每一列都是资源。示例：

building_id | structure_id | energy | food | water
--------------------------------------------------
1           | 1            | 459    | 19   | 0

这种方法的好处是我可以写一些方便的views 和events 并完全从mysql 中支持这个逻辑。我可以每小时触发一个大型更新语句来生成事务。

这种方法的缺点是我必须将每个资源写成表格中的一列。这也将出现在我的数据库表中。我预计只有 150 个左右的资源。

我一直在使用的另一个选项是将其构建为一个基本的库存系统。所以，有一个看起来像这样的stock 表：

stock_id | building_id | resource_id | qty
-------------------------------------------
1        | 1           | 3           | 19
4        | 1           | 2           | 0
5        | 1           | 1           | 459

这种方法的好处是代码的可扩展性，可以轻松输入新资源以增强游戏体验。

这种方法的缺点是我必须执行多个UPDATE 和SELECT 语句才能执行一个buildings 生产。以及每个building。我计划将服务器限制为 250k buildings。这可能会变得很费力。

---

总而言之，我正在寻找最优化的方法。我将拥有一组有限的资源，并且我能够使用查询构建代码来创建升级类来处理添加资源。但这也变成了大量的代码来构建数据库。

有人对此有什么想法吗？

---

编辑： 为了清楚起见，我正在添加生产顺序的工作方式。

1. 建筑物必须检查需要从库存中导入哪些内容，以及将释放多少空间容量。
2. 建筑物必须检查需要将哪些内容导出到库存中，以及它将占用多少空间。
3. 建筑物导入和导出来自structures 表并乘以建筑物等级。 如果我们不超过产能并且我们拥有所有需要的资源，那么构建将改变库存。

这一切，现在可以从所有buildings 上的一个UPDATE 语句正确运行，并且运行速度非常快（尚未在大于100 的集合上进行测试）。但这是基于将每个资源作为一列的设计。我可以使用适当的库存系统样式表实现与现在相同的结构，但我需要 150 个左连接（有 150 个资源）。

Answer 1

放弃 150 个资源列的概念。在分析表 xxxx 调用后，强制连接以索引提示运行。 使用 explain 命令验证计划。通过存储的过程进行调用。

我意识到这是您正在构建的游戏。我用这种结构物品状态玩大型地图游戏 MMOG。数据层经过高度优化，否则会影响用户体验。大量的内存缓存。

数据仅在需要时才重要。您不会接近建筑物并获取有关它的所有属性。这是为什么呢？

1) not needed now. who cares that the antenna is blown. it is irrelevant. you are 90 feet from water, how would u use it anyway 
2) slow
3) becomes stale
that is all pull technology. client manually pulls it

至于从服务器推送（我们有开放套接字的好处） 这些很关键，需要接近实时

1) player positions and how equipped
2) base status. this is important. what is where and state in base. these is constantly grabbed by users from mini-maps
3) your player, stats in particular, partly to prevent hacks
these push 90% of the time resided memcached in the structure most friendly to the client side. cannot seem to get anywhere near this performance

push：不在内存缓存中的东西，而是发生在玩家面前的东西。或在它后面。就像头部中弹一样。

玩家自然不会这么做。它独立于行走、缩放。

显然，没有连接的所有信息都很好。不适合我们