【问题标题】：Html5 local datastore, and sync across devicesHtml5本地数据存储，跨设备同步
【发布时间】：2011-05-05 15:38:29
【问题描述】：

我正在构建一个功能齐全的 Web 应用程序。当然，您可以在“离线”模式下保存到本地数据存储。我希望能够跨设备同步，这样人们就可以在一台机器上工作、保存，然后在另一台机器上加载他们的东西。

问题是：

1) 在服务器上存储 json 是不是一个坏主意？为什么要将服务器上的 json 作为 json 传递回（其他）客户端时将其解析为模型对象？

2) 我不确定我是否想为此尝试 NoSql 技术。我没有分解 json，因为现在数据库中唯一的关系是从用户帐户到他们的条目。除了用户数据，域模型将是一个字符串，即 json。欢迎咨询。

理论上，将来我可能想在服务器上做一些处理或建立更复杂的关系。换句话说，现在我只是保存 json，但将来我可能想要一个更传统的关系系统。 NoSQL 方法会阻碍这一点吗？

3) 这有什么安全问题吗？例如 JS 注入？理论上，对于这个用例，用户不需要输入任何东西，至少现在是这样。

提前谢谢你。

编辑 - 感谢您的答案。我选择了我所做的答案，因为它最详细地介绍了 NoSql 的优缺点。

【问题讨论】：

我认为您不需要大量数据即可考虑使用 noSQL 解决方案。我认为您应该根据其功能选择适合该工作的工具。在这种情况下，CouchDB 可能是完美的，因为它具有强大的复制和离线方法。
@rwilliams -- 是的，我同意。我的问题是：用于存储 json 的“nosql 存储是正确的技术”。除了其他问题。
JSON 是 CouchDB 用来存储其文档的格式，所以我认为它绝对是存储 JSON 的正确技术：P
@rwilliams，不想写详细的答案吗？
添加了答案。理想情况下，我想更多地了解您正在构建的应用程序及其目标受众。

标签： sql json html nosql rich-internet-application

【解决方案1】：

服务器上的 JSON

在服务器上存储 JSON 并不是一个坏主意，尤其是当您使用 MongoDB 或 CouchDB 等 noSQL 解决方案时。两者都使用 JSON 作为它们的原生格式（MongoDB 实际上使用 BSON，但它非常相似）。

noSQL 方法：假设 CouchDB 作为存储引擎

烘焙复制和并发处理
非常简单的 Rest API，通过 HTTP 与数据库通信。
将数据存储为原生 JSON，而不是存储在 blob 或文本字段中
强大的查看/查询引擎可让您继续增加文档的复杂性
离线模式。如果互联网不可用，您可以直接使用 javascript 与 CouchDb 对话，并让整个应用程序继续在客户端上运行。

安全

确保您使用浏览器 JSON.parse 或安全的 Javascript 库 (json2.js) 解析 JSON 文档。

结论

我认为我建议在这里使用 noSQL（尤其是 CouchDB）的原因是它可以为您处理所有困难的事情。复制将是一个快速设置。您不必担心并发等问题。

也就是说，我不知道您正在构建什么样的应用程序。我不知道您与客户的关系是什么，以及让他们将 CouchDB 安装到他们的机器上会有多容易。

链接

更新：

查看应用程序后，我认为 CouchDB 不是一个好的客户端选项，因为您不会要求人们安装数据库引擎来玩数独。也就是说，我仍然认为这将是一个很棒的服务器端选项。如果您想将服务器 CouchDb 实例与客户端同步，您可以使用 BrowserCouch 之类的东西，它是用于本地存储的 CouchDB 的 JavaScript 实现。

【讨论】：

@rwilliams，如果数据存储为 json，那么运行服务器端批处理作业来分析事物的过程是什么？你只是加载和解析并继续你的方式吗？我打算使用 html5 localstorage 来保存客户端数据。除了 couchdb 之外，这将如何工作？不就是一个吗？
要分析事物，您需要使用 CouchDB 的视图引擎编写地图或地图/归约函数。在创建和更新数据库中的所有文档时，此功能会持续应用于它们。该函数使用您选择的键和值创建一个 b 树索引。 ** 除非您真的希望人们能够离线玩游戏，否则我会说这可能是其中之一。如果你想在 CouchDB 之外使用 localdata，你可以使用 BrowerCouch，然后将数据同步到服务器进行处理。之前讲的地图功能也可以在 BrowserCouch 中实现。
@rwilliams，nosql 方法的缺点是什么？做出一些权衡以获得更完整的答案。
缓慢添加 hoc 查询/视图。较小的支持/问题社区。平面命名空间，没有“表”。更大的数据库文件，因为它使用了 copy_on_write（这可以通过定期压缩来缓解）。文档之间没有真正的关系，您必须通过视图引擎关联文档。
@rwilliams，嗯，似乎如果将 json 存储在服务器上，最好使用 nosql，因为可以“查看”数据。使用 RDBMS 必须处理 json 来分析它。对吗？

【解决方案2】：

如果您的大部分处理将在客户端使用 JavaScript 完成，我认为将 JSON 直接存储在服务器上没有任何问题。
如果您只是想玩转新技术，我们非常欢迎您尝试不同的东西，但是对于大多数应用程序来说，没有真正的理由离开传统数据库，而 SQL 让生活变得简单.

【讨论】：

@hvgotcodes：当您拥有大量数据并且您实际上注意到传统数据库正在影响您的性能时。这几乎不会发生，除非，例如，你是谷歌。甚至 Facebook 也只使用 MySQL 数据库和 memcached 来提高性能。
赏金结束前的任何更新，基于其他答案？
@hvgotcodes：我想唯一值得怀疑的是第 (2) 部分，至少在这种情况下，这有点主观/基于个人喜好。 “答案”是你认为最适合你的那个。 :)

【解决方案3】：

刚刚阅读了您的帖子，我不得不说我非常喜欢您的方法，它预示着未来许多 Web 应用程序可能会工作的方式，包括本地存储（用于断开状态）和在线存储（主数据库 - 将所有客户记录保存在一个地方并同步到其他客户端设备）。

这是我的答案：

1) 在服务器上存储 JSON： 我不确定我是否会将对象存储为 JSON，如果您的应用程序非常简单，则可以这样做，但这会妨碍使用数据（例如，运行报告并通过电子邮件发送批处理作业）。我更愿意自己使用 JSON 传输信息，并使用 SQL 数据库来存储它。

2) NoSQL 方法：我想你已经回答了你自己的问题。我的首选方法是现在设置一个 SQL 数据库（如果所需的额外资源不是问题），这样您就可以节省一些为 NoSQL 设置数据访问层的工作，因为您可能不得不删除它将来。如果您不想要功能齐全的 RDBMS，SQLite 是一个不错的选择。

如果编写模式太麻烦，并且您仍想将 JSON 保存在服务器上，那么您可以散列一个 JSON 对象管理系统，使用单个表并在服务器端进行一些解析以返回相关记录。这样做会比保存/删除文件更容易并且需要更少的权限。

3) 安全性：您提到目前没有用户输入：

"对于这个用例，用户不需要可以输入任何内容”

但是在问题的开头你也提到用户可以

"在一台机器上工作，保存，然后获取在另一台机器上加载他们的东西”

如果是这种情况，那么您的应用程序将存储用户数据，您没有为他们提供好的 GUI 来存储用户数据并不重要，您将不得不从多个角度担心安全性，@987654321 @ 或类似的工具只能解决一半的问题（客户端）。

基本上，您还必须在服务器上检查您的 POST 请求的内容，以确定发送的数据是否有效和真实。在保存到数据存储之前，需要在服务器上验证 JSON 对象（或您要保存的任何数据）的完整性（使用 php 或其他类似语言），这是因为有人可以轻松绕过您的 javascript 层“安全性”并篡改 POST 请求，即使您不打算这样做，然后您的应用程序无论如何都会将恶意输入发送到客户端。

如果你整理了服务器端的东西，那么JSON.parse 在防止 JS 注入方面变得有点过时了。拥有额外的层仍然不错，特别是如果您依赖远程网站 API 来获取您的一些数据。

希望这对你有用。

【讨论】：

赏金结束前的任何更新，基于其他答案？
@hvgotcodes，也建议使用简单的 RDBMS 解决方案，使用 1 个表来存储 JSON。