Question

我需要编写一个脚本来管理本地存储中文档的冲突版本。我目前正在考虑两种选择，并且难以确定哪一种更具可扩展性。

我的文档将存储为JSON，并且会有id和revision来标识版本。

目前我正在localstorage中创建一条路径，如下所示：

PATH/TO/DOCUMENT/id

在此路径中，文档存储为JSON

{"id":"abc","version":"1-a","content":"foo"}

我正在使用POST，PUT（更新），GET和REMOVE。 POST / PUT需要id和version，而GET / REMOVE只需要id。

为了允许本地存储中存在冲突的版本，我不确定是否

a）存储在现有路径，并将版本添加为第二个JSON 字符串，如下所示：

PATH/TO/DOCUMENT/id   {"id":"abc","version":"1-a","content":"foo"},
                      {"id":"abc","version":"2-b","content":"foodforthought"}

b）存储在 path.id 并保留“单个文件”

PATH/TO/DOCUMENT/id.1-a   {"id":"abc","version":"1-a","content":"foo"}
PATH/TO/DOCUMENT/id.2-b   {"id":"abc","version":"2-b","content":"foodforthought"}

问题：
哪一个在可扩展性方面更有意义，而且存在许多不同的版本？

Answer 1

哪一个在可扩展性和许多不同版本方面更有意义？

选项B.在这里，您可以读取/写入单个文档版本，而无需将整个JSON字符串（然后是对象，当涉及到操作）加载到内存中。特别是当涉及到许多大型文档时，这将为您节省一些时间。

但是，如果您有一个巨大文档的许多版本相互之间没有太大差异，那么在性能和内存使用方面可能会更好地存储它们incremental或{{3}版本控制，这在一个单独的“JSON文件”中更有意义。

Answer 2

选择选项A：如果每个JSON条目都很小，只有id，而不是整个文档。这很容易管理和清理。

选择选项B：如果每个JSON条目都很大。我同意@Bergi

Answer 3

如果我理解正确，这是一个关于最佳架构的问题。

由于您可能有“很多不同的版本”，因此需要快速查找localStorage，因此选项b更好。因为在选项a中，每当您想要查找文档的特定版本时，您必须遍历其id为abc的所有项目，然后迭代它们（最坏情况：线性搜索）尝试查找版本你在寻找。

但是，使用.（点）作为分隔符可能不是最佳选择。分隔符应该是版本号和文件名中未使用的字符。我建议像/这样的东西。所以键就像：

PATH/TO/DOCUMENT/id/1-a   {"id":"abc","version":"1-a","content":"foo"}
PATH/TO/DOCUMENT/id/2-b   {"id":"abc","version":"2-b","content":"foodforthought"}

我应该通过document_id还是document_id_version在localstorage中存储多个版本的文档？

3 个答案: