使用 SQL 处理 'very large' 库存的最佳方法是什么？
What’s the best way to handle an 'very large' inventory with SQL?
我正在考虑制作一款类似于《炉石传说》的在线纸牌游戏。玩家将拥有无限的库存来存储他们拥有的所有卡片。
使用这种方法，每个玩家卡组合的数据量都会非常大，因此呈指数增长。
本来想要3个table的:
一个Player_Table
| Player_ID | Player_Name | Rank | Icon | ect...
一个Card_Table
| Card_ID | Card_Name | Attack | Defence | ect...
然后 Inventory_Table 给他们
| Player_ID | Card_ID | Quantity |
然后我可以使用像 SELECT Card_ID FROM Inventory_Table WHERE Player_ID=YourID
这样的语句
显然，这里存在缩放问题，我添加的卡片越多，加入的玩家越多，获取卡片列表所需的时间就越长。
我正在考虑使用像 MongoDB 这样的东西作为 NoSQL 的替代品来帮助解决这可能导致的潜在性能问题，但后来我发现它不像 mySQL 那样可以免费用于商业用途，所以我放弃了那个计划。
我想到的第三个也是最后一个想法是动态添加 tables。创建玩家（创建帐户）时，我可以添加名称为 "Player_Cards_" + Player_ID（例如 Player_Cards_318）的 table想法，但我不确定。
请有人指出正确的方向。
Obviously, there is a scaling issue here where the more cards I add, and the more players
join the longer this will take to get your card list.
不，不是你想的那样。假设您使用指数，增长将是对数的——不是线性的。更像是 "twice as long for 25 times the entries".
I was thinking about using something like MongoDB as a NoSQL alternative to help with
the potential performance issues that this would cause
没有。正如我所说，除了性能问题主要是一种错觉之外，nosql 对关系问题并没有特别的帮助，到目前为止你显示的是一个实际问题 ;)
The 3rd and final idea I came up with was dynamically adding tables. when a player is
created (creates an account)
对于在公司工作的任何人来说，这都是可以终止的违规行为。它基本上使大量分析完全不可用，并导致很多小表，这通常是一种反模式（数据库未为此进行优化，因此您最终将开始浪费资源来寻找任何专业团队都会向您展示的解决方案门.
使用方案一，完成。你的 sacaiability 问题并没有你瘦那么严重（特别是如果你添加了一个分片层），并且由于缺乏用户，你可能根本不会 运行 进入它。
table 中的数百万行通常不是问题。数十亿行令人兴奋，但并非不可能。请计算一下并得出一个粗略的估计。
同时，请提供SHOW CREATE TABLE以便我们了解涉及的数据类型、引擎和索引。
不要为每个用户（或每个用户）创建一个新的 table。这是一个经常被问到的问题；答案总是 "no".
SELECT Card_ID FROM Inventory_Table WHERE Player_ID=YourID
是一个非常基本的查询。任何 starting 和 Player_ID 的索引都将允许非常快地执行该查询（毫秒）。 INDEX(Player_ID, Card_ID) 可能会更快。您还有哪些其他常见问题？
缩放...一个简单的经验法则是“每行 100 个字节”。计算所有 table 中的所有行需要多少字节；那会适合你的磁盘吗？ （我怀疑它会。）
您将在单个 SELECT 中触及其中的 2 或 3 个 table。所以学习如何做 SQL JOIN.
回复"logarithmic"：万亿行中的"point query"大约是百万[=35行中的两倍=]行。
我对 "no sql" 的看法 -- 您必须重新发明 SQL 才能完成任务。在此过程中，您将学到很多 RDBMS 会为您做的优化技术。
我正在考虑制作一款类似于《炉石传说》的在线纸牌游戏。玩家将拥有无限的库存来存储他们拥有的所有卡片。
使用这种方法，每个玩家卡组合的数据量都会非常大，因此呈指数增长。
本来想要3个table的:
一个Player_Table
| Player_ID | Player_Name | Rank | Icon | ect...一个Card_Table
| Card_ID | Card_Name | Attack | Defence | ect...然后 Inventory_Table 给他们
| Player_ID | Card_ID | Quantity |
然后我可以使用像 SELECT Card_ID FROM Inventory_Table WHERE Player_ID=YourID
这样的语句显然，这里存在缩放问题，我添加的卡片越多，加入的玩家越多，获取卡片列表所需的时间就越长。
我正在考虑使用像 MongoDB 这样的东西作为 NoSQL 的替代品来帮助解决这可能导致的潜在性能问题，但后来我发现它不像 mySQL 那样可以免费用于商业用途，所以我放弃了那个计划。
我想到的第三个也是最后一个想法是动态添加 tables。创建玩家（创建帐户）时，我可以添加名称为 "Player_Cards_" + Player_ID（例如 Player_Cards_318）的 table想法，但我不确定。
请有人指出正确的方向。
Obviously, there is a scaling issue here where the more cards I add, and the more players join the longer this will take to get your card list.
不，不是你想的那样。假设您使用指数，增长将是对数的——不是线性的。更像是 "twice as long for 25 times the entries".
I was thinking about using something like MongoDB as a NoSQL alternative to help with the potential performance issues that this would cause
没有。正如我所说，除了性能问题主要是一种错觉之外，nosql 对关系问题并没有特别的帮助，到目前为止你显示的是一个实际问题 ;)
The 3rd and final idea I came up with was dynamically adding tables. when a player is created (creates an account)
对于在公司工作的任何人来说，这都是可以终止的违规行为。它基本上使大量分析完全不可用，并导致很多小表，这通常是一种反模式（数据库未为此进行优化，因此您最终将开始浪费资源来寻找任何专业团队都会向您展示的解决方案门.
使用方案一，完成。你的 sacaiability 问题并没有你瘦那么严重（特别是如果你添加了一个分片层），并且由于缺乏用户，你可能根本不会 运行 进入它。
table 中的数百万行通常不是问题。数十亿行令人兴奋，但并非不可能。请计算一下并得出一个粗略的估计。
同时，请提供SHOW CREATE TABLE以便我们了解涉及的数据类型、引擎和索引。
不要为每个用户（或每个用户）创建一个新的 table。这是一个经常被问到的问题；答案总是 "no".
SELECT Card_ID FROM Inventory_Table WHERE Player_ID=YourID
是一个非常基本的查询。任何 starting 和 Player_ID 的索引都将允许非常快地执行该查询（毫秒）。 INDEX(Player_ID, Card_ID) 可能会更快。您还有哪些其他常见问题？
缩放...一个简单的经验法则是“每行 100 个字节”。计算所有 table 中的所有行需要多少字节；那会适合你的磁盘吗？ （我怀疑它会。）
您将在单个 SELECT 中触及其中的 2 或 3 个 table。所以学习如何做 SQL JOIN.
回复"logarithmic"：万亿行中的"point query"大约是百万[=35行中的两倍=]行。
我对 "no sql" 的看法 -- 您必须重新发明 SQL 才能完成任务。在此过程中，您将学到很多 RDBMS 会为您做的优化技术。