虽然有很多关于html5的好东西，但我没有得到的一件事是redondant存储机制，首先是localstorage和sessionstorage，它们是键值存储，一个是应用程序的一个实例（“一个选项卡“），另一个适用于该应用程序的所有实例，以便他们可以共享数据。当你关闭浏览器并且大小有限（通常是5MB）时，两者都会被保存，这很好，如果我们停在那里，一切都会很好。
但是有一个“Web SQL数据库”，它具有与localstorage相同的安全系统，相同的大小限制，除了它的工作原理之外的所有内容都像/ sqlite一样，具有表和sql语法以及所有这些。
令人头疼的是，他们完全无法处理相同的数据！这不是访问数据的两种方式，这对于每个html 5应用程序来说真的是两个存储空间（默认情况下不是创建的，但是你仍然看到了我的观点）。
我想知道的是，这两种机制同时存在的原因是什么？或者他们只是看看sql和nosql运动来挑选最好然后去“拧它让我们加两个！” ？为什么不将本地/会话存储实现为web sql db中的表？
答案 0 :(得分：5)
我认为本地存储是对cookie应该首先进行的正确改写。它具有非常简单的api和低采用率。
Web SQL是一项非常重要的任务，如果只保存一个简单的值，那将是一个非常痛苦的问题，因此它们具有非常不同的用例。 localstorage实际上是使用SQLite在WebKit中实现的，但是没有通过WebSQL公开。
会话存储无法在数据库内轻松实现，因为它实际上是在全局范围内，并且您不希望数据对其他选项卡可见。因为它是瞬态数据，所以通常不想存储批次，因此不需要事务和查询。
答案 1 :(得分：0)
我问自己同样的问题，这是答案，引自Chromium维基：
问：为什么选择LocalStorage？
答： LocalStorage本身就是一种生机勃勃的态度 并行性灾难，取决于 不管你是否愿意 实现“存储互斥” 在规范中描述。铬有 决定不实施它。 WebKit的 本身是单线程/进程（即 没有平行期）
资料来源： http://www.chromium.org/developers/design-documents/indexeddb
如果要在本地复制数据库结构以供脱机使用，则Web SQL非常有用。
但是在Firefox中不会实现Web SQL： http://us1.campaign-archive.com/?u=168bf22f976f5a68fe5770d19&id=6c2d73c957#standards
Mozilla，Microsoft和Oracle正在开发“IndexedDB”替代方案：http://www.w3.org/TR/IndexedDB/
在firefox中进行了正在进行的工作：https://wiki.mozilla.org/Firefox/Projects/IndexedDB
存储演示：