Questions tagged «indexeddb»

我有一个使用appcaching的脱机Web应用程序。我需要提供大约10MB-20MB的数据（客户端），该数据主要由PNG图像文件组成。操作如下： Web应用程序下载并安装在appcache中（使用清单） 来自服务器PNG数据文件的Web应用请求（如何？-请参见下面的替代方法） 有时，Web应用程序会与服务器重新同步，并对PNG数据库进行少量的部分更新/删除/添加 仅供参考：服务器是JSON REST服务器，可以将文件放在wwwroot中以进行提取 这是我目前对处理二进制Blob存储的基于客户端的“数据库”的分析 在底部查看更新 AppCache（通过清单添加所有PNG，然后按需更新） 缺点：PNG数据库项目的任何更改都意味着完整下载清单中的所有项目（真的是坏消息！） 网络存储 CON：专为JSON存储而设计 CON：只能通过base64编码存储Blob（由于解码成本高，可能是致命缺陷） CON：webStorage的5MB硬限制http://htmlui.com/blog/2011-08-23-5-obscure-facts-about-html5-localstorage.html PhoneGap和SQLLite 缺点：赞助商将其拒绝为需要认证的本地应用 ZIP文件 服务器创建一个zip文件，将其放在wwwroot中，并通知客户端 用户必须手动解压缩（至少我是这样）并将其保存到客户端文件系统 Web应用程序使用FileSystem API引用文件 缺点：ZIP可能太大（zip64？），创建时间很长 缺点：不确定FileSystem API是否可以始终从沙箱中读取（我认为是） USB或SD卡（回到石器时代。...） 用户将在离线之前位于服务器本地 这样我们就可以让他插入SD卡，让服务器用PNG文件填充 然后用户将其插入笔记本电脑，平板电脑 Web应用程序将使用FileSystem API读取文件 缺点：不确定FileSystem API是否可以始终从沙箱中读取（我认为是） WebSQL 缺点：w3c放弃了它（非常糟糕） 我可能会考虑使用IndexedDB和WebSQL作为后备的Javascript包装器 文件系统API Chrome支持读/写Blob 缺点：不清楚IE和FireFox（IE10，具有非标准msSave） caniuse.com报告了IOS和Android支持（但同样，这仅仅是JSON的读/写，还是它包含用于编写的完整blob API？ 缺点：FireFox员工不喜欢FileSystem API，也不清楚他们是否支持保存Blob：https：//hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/ PRO：很多比IndexedDB的更快斑点根据jsperf http://jsperf.com/indexeddb-vs-localstorage/15（第2页） 索引数据库 IE10和FireFox的良好支持（保存，读取blob） 比文件系统更好的速度和更轻松的管理（删除，更新） 专业人士：请参阅速度测试：http : //jsperf.com/indexeddb-vs-localstorage/15 …

105 javascript  html  web-applications  indexeddb  leaflet 

我正在一个涉及使用IndexedDB的项目中。当我开始了解这项技术时，我需要能够手动删除indexedDB，以便重新开始。 我找到了在Firefox中执行此操作的方法，但找不到适用于Google Chrome的方法。 我尝试删除此文件夹的内容（我使用的是Mac）： {home}/Library/Application Support/Google/Chrome/Default/IndexedDB 但似乎Chrome stil到处都有数据库，所以我无法重新开始。

92 google-chrome  indexeddb 

indexedDB和本地存储都是键值存储。拥有两个键/值存储区有什么优势？ indexedDB是异步的，但是联接（最耗时的事情）是手动的。它们似乎在与异步调用相同的线程中运行。这如何不会阻止UI？ indexedDB允许更大的存储。为什么不增加HTML5商店的大小？ 我挠头。indexedDB的意义是什么？

84 javascript  html  indexeddb 

问题： 我需要一个与设备无关的解决方案（例如HTML5），用于在电话或平板电脑类型的设备（例如iOS / Android）上离线存储和查询250,000多行数据。我的想法是让人们在没有任何蜂窝数据连接的情况下在偏远地区工作，他们需要对此数据运行查询并在脱机时对其进行编辑。部分将基于地理位置，因此，如果资产所在的区域中有资产（使用GPS），则它将显示这些资产并进行编辑。当他们返回办公室时，他们可以将数据同步回办公室服务器。 我从Web标准的角度来解决这个问题的原因基本上是为了节省金钱和时间，方法是在HTML5中编写一次，然后在多个平台上工作，而不是在Objective C和Java中编写两次。同样，如果您编写的内容与平台无关，那么您就不会被锁定，并且当每个人都迁移到更新的版本时，都不会陷入困境。我们有一个为Windows Mobile 5编写的类似应用程序，但由于该平台已失效，它已无用。 设备上的离线数据库必须为： 快速（响应时间少于2秒） 可能执行联接并与能够查询数据库的其他表有关系 根据GPS读数，通过x和y坐标选择某个范围或标准内的数据。 选项： HTML5本地存储： 对于少量<5,000个键/值的数据，如果将其转换为JSON，您甚至可以在其中存储数组/对象。 缺点： 即使在高端计算机上，超过10,000行的浏览器也会缓慢爬行。 无法对数据进行复杂的查询以提取所需的数据，因为您必须遍历整个存储并手动搜索它。 可以存储的存储空间的限制 Web SQL数据库： 符合要求。 快速在250,000行上运行查询（1-2秒） 可以创建复杂的查询，联接等 受Safari，Android和Opera支持，因此可在iOS和Android设备上使用 缺点： 自2010年11月起弃用 跨目录攻击的安全漏洞。并不是真正的问题，因为我们不会共享托管 IndexedDB： 键/值对象存储与本地存储类似，但带有索引。 缺点： 缓慢地对200,000行执行查询（15-18秒） 无法运行复杂的查询 不能与其他表联接 主要电话或平板电脑设备（例如iPad / Android）不支持 标准不完整 这就留下了实现不推荐使用的Web SQL方法的唯一选择，该方法只能再使用一年左右。目前，IndexedDB和本地存储不可用。 我不确定Mozilla和Microsoft如何弃用Web SQL数据库标准，以及W3C为何允许它发生。据推测，它们之间拥有台式机浏览器市场的77％。在先进的移动设备上，Mozilla和Microsoft的影响力几乎为零，因为Safari，Opera和Android占据了90％以上的市场份额。Mozilla和Microsoft如何决定应该在移动市场中使用哪个标准，而在哪个市场中最有可能使用脱机存储，这没有任何意义。 Mozilla在关于为什么要使用IndexedDB的评论中，主要是关于“开发者审美”的，他们不喜欢在JavaScript中运行SQL的想法。我不买。 目前，提出的标准还很差，并且是一个极其基本的NoSQL实现，该实现很慢，甚至不支持人们在数据库中所需的高级功能。建立数据库和获取数据有很多样板代码，但他们声称人们会在其顶部编写一些不错的抽象库，这些库将提供更多高级功能。截至2011年10月，它们无处可寻。 他们已经弃用了现有的Web SQL标准，该标准实际上有效并已在主要的移动/平板电脑浏览器中实现。而在主要的移动浏览器中没有它们的“新”和“更好”标准。 在接下来的3-5年中，作为IndexedDB规范可能逐步标准化，具有更多功能，在主要的移动/平板电脑浏览器中实现的功能以及一些易于使用的好的库，开发人员应该使用什么？ W3C应该保持Web SQL数据库标准并行运行，并解决问题。它已经支持主要的移动平台，并且运行良好。Mozilla和Microsoft作为拥有最多桌面浏览器份额的两个播放器能够取消此标准的事实是相当可疑的，并且可以被视为试图阻止移动Web平台上的进展，直到他们能够赶上并提供该标准。与iOS / …

74 javascript  html  web-sql  indexeddb  jaydata