IndexedDB 对象键：大小重要吗？答案

【问题标题】：IndexedDB object keys: does the size matter?IndexedDB 对象键：大小重要吗？
【发布时间】：2012-09-11 07:59:34
【问题描述】：

我即将在 indexeddb 对象存储中存储大量对象。所有对象都具有相同的结构，例如{somekey: xxx, somevalue: yyy}。

对象键的长度会影响存储数据的大小吗？例如，如果我将结构更改为{s: xxxx, v: yyyy}，我是否应该期望使用当前浏览器在对象存储中获得更好的足迹？

我在标准中的任何地方都找不到有关此的任何信息，所以我想内部是否使用字典取决于浏览器的实现，我想了解它目前是如何实现的，以及是否减少存储对象键的大小是值得优化的。

【问题讨论】：

【解决方案1】：

是的，它会影响它。但至少对于大小合理的键，一个字符与 10 或 20 个字符不会对性能产生任何影响，除非您的规模非常大（数百万条记录）。大多数实现（包括我可以说的chrome）确实存储了包括键名在内的完整对象，但索引只存储“keypath”一次..

这意味着 {"foo": "bar"} 可能需要大约 12 个字节来存储（每个字符串大约 4 个字节加上一些类型信息开销，但是 "foo" 上的后续索引将只存储 "巴兹”。

{"foobarbaz": "helloworld"} 可能需要大约 23 个字节来存储。真的，我希望在大多数情况下，您自己的数据应该超过密钥长度的开销，并且尝试缩短您的密钥以节省几个字节是过早的优化。

【讨论】：

感谢您的回答，但我的问题更多是关于存储空间而不是性能。例如，使用您的示例，如果我存储 {"foobarbaz": "helloworld"} 二十次，当前实现使用〜23bytes x 20，或者是存储在字典中的键，并在结构中引用（暗示在所有对象中使用的长键名不会显着影响存储配额）
对不起，我想我可能有错误的名字，当我说键时，我的意思是存储的结构化对象中的属性名称......
是的，我说的是存储空间，通常是的，对象被存储了 20 次，至少在我知道的实现中。