我正在构建一个不如传统的股票系统来为浏览器/手机游戏提供动力。基本主体是building具有某些stock的{{1}}。这些resources每小时生产一次，减少进口，并在每栋建筑物中产生出口。制作基于buildings作为structure的类型以及建筑物级别和容量。
我的困境是如何以可扩展的方式布局这些库存表。我能够构建表，以便每列都是一个资源。例如：
building这种方法的好处是我可以编写一些方便的building_id | structure_id | energy | food | water
--------------------------------------------------
1 | 1 | 459 | 19 | 0
和views，并从mysql中完全支持这个逻辑。我可以每小时向交易产品发一个大的更新声明。
此方法的缺点是我必须将每个资源编写为表格中的列。这也将出现在我的数据库表中。我预计只有150左右的资源。
我一直在玩的另一个选项是将其构建为基本库存系统。所以，有一个events表，如下所示：
stock此方法的好处是代码可以轻松输入新资源以增强游戏效果。
此方法的缺点是我必须执行多个stock_id | building_id | resource_id | qty
-------------------------------------------
1 | 1 | 3 | 19
4 | 1 | 2 | 0
5 | 1 | 1 | 459
和UPDATE语句才能生成一个SELECT。以及每个buildings。我计划服务器限制为250k building。这可能会变得很累。
总而言之，我正在寻找最佳方式。我将拥有一组有限的资源，并且我能够使用查询构建代码来创建升级类来处理添加资源。但这也成为构建数据库的一大堆代码。
有人对此有任何想法吗？
编辑： 为了清楚起见，我正在添加生产顺序的工作原理。
buildings表，并乘以建筑物级别。
如果我们不超过容量并且我们拥有所有需要的资源，那么构建将改变库存。 这一切现在正确地从所有structures上的一个UPDATE语句正确运行，并且非常快（未在大于100的集合上测试）。但这是基于每个资源作为列的设计。我可以使用适当的库存系统样式表实现与现在相同的结构，但我需要150个左连接（有150个资源）。
答案 0 :(得分：1)
抛弃150个资源列概念。在分析表xxxx调用之后，强制连接使用索引提示进行操作。 使用explain命令验证计划。通过存储过程进行调用。
我意识到这是你正在构建的游戏。我做了大型地图游戏玩MMOG这样的结构项目状态。数据层经过高度优化，否则将会影响用户体验。很多memcache。
数据仅在需要时才重要。你不接近建筑物并获取它的每个属性。那是为什么？
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
推送：东西不在memcache中，而是发生在玩家面前。或者在它后面。喜欢在头部射击。
自然，玩家并没有拉动它。它独立地发生在行走，缩放上。
显然没有连接的所有信息的行是很好的。不适合我们