Protobuf，嵌套地图？答案

【问题标题】：Protobuf, nested maps?Protobuf，嵌套地图？
【发布时间】：2016-08-10 03:14:45
【问题描述】：

我正在使用 Protobuf 3。从文档来看，似乎无法定义嵌套地图：

message MyMessage {
  map<string, map<string, string>> nestedMap = 1; // doesn't work
}

我正在尝试创建一个消息类型来表示期权链的定价信息（买入价和卖出价）。对于那些不熟悉这些金融工具的人，基本上，我有一套“到期日（YYYYMMDD）”。在每个到期日期中，我都有一组“罢工（浮点数；如有必要，可以表示为字符串，我可以接受）”。在每次罢工中，我有 2 个选项，一个“看跌”和一个“看涨”（这被称为选项的“权利”）。这些选项中的每一个都包含“出价”和“要价”。

从概念上讲，我想要类似的东西

message OptionChain {
  // doesn't work:
  map<Expiration, map<Strike, map<Right, BidAskData>>> whatever = 1;
}

我找到的替代方案是这样的：

message OptChain {
  map<string, OptChainExpirations> expirations = 1;
}
message OptChainExpirations {
  map<string, OptChainExpirationsStrikes> strikes = 1;
}
message OptChainExpirationsStrikes {
  OptBidAsk put = 1;
  OptBidAsk call = 2;
}
message OptBidAsk {
  double bid = 1;
  double ask = 2;
  // any other fields that might be necessary in the future
}

这似乎有效。但是，通过定义大量“中间”消息，这似乎也给我的系统增加了不必要的复杂性。

还有其他选择吗？

谢谢！

编辑：一些额外的上下文：

一个期权链通常包含不超过 6-10 个不同的到期日，每个到期日通常不会包含超过几十个行使价。换句话说，我们所说的每个选项链最多需要几千字节的数据。
我将使用它作为一个 gRPC 调用的返回值。随意为此建议替代设计！

【问题讨论】：

标签： protocol-buffers

【解决方案1】：

对我来说，中间消息类型的替代方案似乎很好。稍微简化一下命名可能是值得的，例如Strike 而不是 OptChainExpirationsStrikes。如果您担心名称冲突，请将其全部放在自己的命名空间/包中。

还要考虑您是否会根据字符串键查找罢工，或者作为普通重复字段是否会更好。

【讨论】：