Tag: web sql

HTML5 IndexedDB，Web SQL数据库和浏览器大战

我开始开发具有脱机数据库存储要求的Web应用程序。 长话短说，应用程序应该可以运行在： Chrome首选桌面浏览器之一 iOS上的Safari Android的原生浏览器（基于V8和WebKit） 所以问题是select哪种技术：IndexedDB或Web SQL数据库？ 关于Web SQL数据库，一方面可以在任何一种情况下使用。 另一方面，Mozilla声称Firefox永远不会实现它，并且根据HTML5 工作草案的规范已经陷入了僵局： 这个规范已经陷入僵局：所有感兴趣的实现者都使用了相同的SQL后端（Sqlite），但是我们需要多个独立的实现来沿着标准化path前进。 在另一个实现者对实现这个规范感兴趣之前，SQL方言的描述只是对Sqlite的一个引用，这对于一个标准是不可接受的。 如果您是实现独立SQL后端的实现者，请联系编辑，以便他可以编写一个方言规范，从而使规范向前迈进。 IndexedDB是Mozilla推崇的另一种select，但它只会在Firefox 4中出现.Microsoft感兴趣，Chrome也会支持它。 我对于苹果公司关于IndexedDB的计划一无所知。 我个人倾向于selectWeb SQL数据库，但仅仅因为我习惯了SQLite，我喜欢SQL的强大function和performance力，而且我理解了关系模型。 IndexedDB对我来说是一个不确定的因素。 这就是说，我害怕在错误的马上投注。 即使IndexedDB成为标准，假设对Web SQL数据库的支持将继续存在是否安全？ （关于CouchDB的一个注释：你也可以把它看作是一种替代方法吗？）

如何以编程方式删除WebSQL中的数据库？

我是新的Web SQL数据库 ，我用它来保存数据在本地数据库中的网页。 我可以通过创build一个数据库 var db = openDatabase('database', '1.0', 'my database', 2 * 1024 * 1024); 我可以通过这个来创build一个表格 db.transaction(function (tx) { tx.executeSql('CREATE TABLE IF NOT EXISTS mytable (blah,blah)'); }); 我可以通过删除 表格 db.transaction(function (tx) { tx.executeSql('DROP TABLE mytable'); }); 但有没有办法通过编程方式删除database ？

Android和iOS上的本地存储有多久？

当我的应用程序在手机上存储本地数据时，该存储是多久？ 我将详细说明确切的情况： 我使用jQueryMobile和Phonegap构build了一个应用程序。 它本质上是一个浏览器应用程序，但使用Phonegap可以将其打包并在应用程序商店中出售，以及其他优点。 Phonegap提供了两种存储方式，这两种方式协调iOs，Android，Blackberry和其他一些操作系统的本地function：localStorage（原始键值对）和Web SQL数据库。 localStorage和Web SQL都是属于浏览器的存储forms。 话虽如此，我不知道数据将保存多久，在什么情况下将被删除，在什么情况下可能无法使用等等。 例如，如果应用程序使用localStorage或Web SQL存储数据，并且用户在其Android上切换到不同的标准浏览器，那么应​​用程序是否会使用新的浏览器打开，这是否意味着存储的数据不可用？ 如果用户一年不使用该应用程序（在我的情况下，这是一个现实的，并不一定是一个坏的情况），数据是否会像Cookie一样过期，或者可能被浏览器的存储来自其他应用的数据？ 或者数据会被更早的销毁，例如： – 用户在浏览器中访问另一个站点 – 浏览器被手工closures – 浏览器进程被终止或死亡 – 等等 或者localStorage和web SQL是您只在Android（Android）中进入“设置”>“应用程序”时才删除的存储types，并主动删除与该应用程序关联的用户数据？ 感谢您的任何见解。 在WWW上没有任何信息。 在应用更新的情况下会发生什么？ 本地和networking存储将被删除或将留下来？

在2011年开发适用于iOS / Android的HTML5离线存储解决scheme

问题： 我需要一个设备不可知（如HTML5）解决scheme，以在手机或平板电脑types的设备（例如iOS / Android）上存储和查询250,000多行数据。 这个想法是我有人在偏远地区工作，没有任何手机数据连接，他们需要对这些数据运行查询和离线编辑。 部分将基于地理位置，所以如果他们所在地区有资产（使用GPS），那么它将显示这些资产，并让它们被编辑。 当他们回到办公室时，他们可以将数据同步到办公室服务器。 我从Web标准的angular度来看待这个问题的原因基本上是通过在HTML5中编写一次而节省金钱和时间，然后跨多个平台工作，而不是在Objective C和Java中编写两次。 另外，如果你写的东西是平台不可知的，那么你就不会被locking在船上，而当每个人都移动到新船上的时候，也不会停下来。 我们有一个为Windows Mobile 5编写的类似的应用程序，现在没用了，因为这个平台已经死了。 设备上的离线数据库需要是： 快（2秒以下的响应） 可能执行连接并与其他能够查询数据库的表有关系 select一定范围内的数据或标准，例如基于GPS读数的x和y坐标。 选项： HTML5本地存储： 对于less量数据<5,000个键/值，如果将其转换为JSON，甚至可以将数组/对象存储在其中。 缺点： 即使在高端机器上，对于超过10,000行，浏览器也会慢慢爬行。 无法对数据执行复杂的查询以提取所需的数据，因为您必须迭代整个存储并手动search。 可以存储的存储量限制 Web SQL数据库： 满足要求。 快速运行250,000行查询（1-2secs） 可以创build复杂的查询，连接等 由Safari，Android和Opera支持，因此可以在iOS和Android设备上运行 缺点： 截至2010年11月已弃用 跨目录攻击的安全漏洞 不是一个真正的问题，因为我们不会共享主机 IndexedDB的： 除索引外，键/值对象存储与本地存储类似。 缺点： 慢速运行一个查询200,000行（15-18secs） 无法运行复杂的查询 无法与其他表连接 不受主要手机或平板电脑设备的支持，例如iPad / Android 标准不完整 这留下了实现已过时的Web SQL方法的唯一select，该方法可能只能工作一年左右。 IndexedDB和本地存储目前无法使用。 我不确定Mozilla和Microsoft如何获得Web SQL数据库标准，以及W3C为什么会这样做。 据说他们之间有77％的桌面浏览器市场。 在先进的移动设备上，Mozilla和微软几乎没有影响，因为Safari，Opera和Android的市场份额超过90％ 。 如何Mozilla和微软可以决定哪个标准应该在移动市场中使用，哪个离线存储最有可能被使用，这没有任何意义。 在Mozilla的评论中，他们为什么要使用IndexedDB而不是“开发人员美学”，他们不喜欢在JavaScript中运行SQL的想法。 我不买它。 […]