0

想法是这样的：我预计会收到数千个查询，每个查询都包含一定数量的名称值对；这些从关联数组开始，因此我可以很好地控制数据可能发生的情况。这些 NVP 因来源而异。例如，如果源是“A”，我可以接收数组（为了便于解释，使用 JSON 格式）：{'Key1':'test1','key2':'test2'}但如果源是“B”，我可以接收{'DifferentKey1':'test1','DifferentKey2':'test2'}我正在选择要存储在数据库中的键，所以在这种情况下，我只想DifferentKey1从源 B 的数组中进行选择，然后丢弃其余的。

我的主要问题是这些数组在技术上可能是完全不相关的内容。它们有一个非常普遍的关联（它们都是包含统计数据的数组），但它们非常不同（因为来源不同，即不同的游戏/运动）。

我在想 SQL：存储一个充满游戏及其各自 id 的表将是链接一般 NVP 字符串的好方法。例如：

Games table:
| id | name |
-------------
  1    golf
  2    soccer

NVP table
| id | game_id | nvp
   1      1      team1score=87;team2score=94;team3score=73;
   2      2      team1score=2;team2score=1;extratime=200;numyellowcards=4;

希望这足够清楚。你明白我的意思吗？如果我可能使用的数据量不确定，我该如何构建表格？谢谢。

编辑：我想我应该注意，显然这个设置会起作用，但是它是最好的性能吗？也许不吧？不太清楚，看看大家有什么办法！

4

2 回答 2

0

SQL 数据库非常适合高度相关的数据 - 但在这种数据不是关系且没有固定模式的情况下，您最好使用 NoSQL 解决方案。有很多，我还没有充分使用它们来确定什么最适合你。如果您的数据可以放入 RAM，那么 redis 就很棒。

于 2012-06-13T01:46:40.983 回答
0

在关系数据库中存储名称/值对的常用方法称为“实体/属性/值”。你会发现很多关于Stack Overflow的讨论。

这完全取决于您的应用程序想要对数据做什么。存储很容易 - 查询要困难得多。

如果您正在构建一个体育应用程序，您可能有想要支持的领域概念 - 对于足球，根据所玩的比赛显示联赛排名。对于高尔夫，显示小鸟或老鹰的数量。您可能希望显示特定球队/球员在一个赛季中参加的所有比赛。

有些东西很容易在关系数据库中构建，并且在庞大的数据集上具有惊人的性能。找到有史以来得分最高的比赛，找到 1998 赛季的最后一场比赛，找到所有以球员 x 为主角的比赛——只要你能建立一个代表这些领域概念的模式，一切都非常合适。

从您所写的内容来看，听起来您将进行固定数量的运动；进入您系统的数据听起来好像不是特别结构化，但您应该能够将其结构化为域模型。如果这是真的，我建议构建一个反映每项运动的领域逻辑的关系模式。

如果这不是真的——如果你不能提前对领域进行推理——关系模型不合适，而 NoSQL 可能更好。但是你会遇到同样的问题——从名称/值对中提取意义是很困难的！

于 2017-08-21T13:32:40.217 回答