我面临的情况是，我正在尝试以最佳方式（在内存存储使用方面）来表示不同商店在不同时间点持有的库存。设置如下：
表：商店
表格是不同商店的列表：
表：股票
表：Store Stock Holdings
（商店ID，库存ID和日期充当联合主键，商店ID和库存ID作为外键）
或者我认为将股票存量存储为json字符串：
表：Store Stock Holdings
例如，假设商店1在2011年1月1日有50个柠檬（代码= 1），100个橙子（代码= 2）和20个芒果（= 3），那么这三个设置将表示为：< / p>
选项1：
Store Id, Stock Id, Date, Quantity
1 , 1, 2011-01-01, 50
1 , 2, 2011-01-01, 100
1 , 3, 2011-01-01, 20
选项2：
Store Id, Date, Stock Holdings
1 , 1, 2011-01-01, \{1,50;2,100;3,20\}
选项3：
通过将日期分为两个表来减少存储选项1中日期的复制，如下所示：
Index, Store Id, Date
1, 1, 2011-01-01
Index, Stock Id, Stock Holdings
1, 1, 50
1, 2, 100
1, 3, 20
所以问题是：
对于不同的实现，我的速度和存储注意事项是什么。我认为选项3和选项2可能是更好的选择，因为日期信息不会被复制。
对于选项2，是存储动态分配的JSON字符串的内存吗？我的意思是JSON字符串可能非常大，因此需要允许它。那么新条目是否会占用总分配或仅占用基于JSON字符串的所需内存量？我的理解是使用varchar将动态分配内存。你会建议使用varchar吗？
答案 0 :(得分：1)
MySQL是一个关系数据库管理系统，因此它被设计为对规范化的关系数据进行操作。
这意味着它无法有效地索引JSON字符串：您无法说，有效地按stockId搜索，按库存运行聚合查询分组等。
你唯一可以快速做的就是在给定商店ID的情况下检索所有商店内容（无论你是否需要）。
因此，如果您使用2作为纯键值存储，则选项MySQL才可行。市场上有许多系统更适合这个目的。
至于在选项1和选项3之间进行选择，后者只是用代理项(storeId, date)替换自然复合键index。
整数的大小比INT + DATE组合短，因此当此选项更好时可能会出现边缘情况（特别是如果您在每个日期的日期很少，并且您不需要查询所有商店或所有日期给予股票）。但是，将所有内容保留在一个表中可让您在storeId，stockId和date的任意组合上创建复合索引，这对性能至关重要。
为了帮助您在两者之间进行选择，我们需要知道您将运行哪种类型的查询，但我需要option 1（storeId，stockId和date一张桌子肯定是选择的典范。