[转载]HTML5 Storage Wars - localStorage vs. IndexedDB vs. Web SQL

最新推荐文章于 2025-02-28 10:37:39 发布

转载最新推荐文章于 2025-02-28 10:37:39 发布 · 3.3k 阅读

html5 同时被 2 个专栏收录

8 篇文章

订阅专栏

sqllite

2 篇文章

订阅专栏

本文对比分析了HTML5中用于本地存储数据的三种技术：WebStorage、IndexedDB API和WebSQL Database，从简单API、可用性、功能性和浏览器兼容性等方面进行了详细阐述。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Currently, there are three competing approaches for saving serious amounts of data (i.e., persistently, and bigger than cookies) locally in your browser:

These names sure seem similar. But the implementations sure are different. Let's quickly summarize what they do, the PROs and CONs, and what I like best at the moment. Though I'm sure my opinions will age quickly as the technology matures.

All these technologies use the same-origin protection for data access (i.e., javascript can only access data from the url's domain that it was served from), which is fine and not a differentiator so I won't mention that below.

Web Storage

Web Storage, and specifically the localStorage part of it, is a really simple key/value persistence system.

PRO: Really simple API.

PRO: Already available in all major new browsers.

CON: No query language, schemas, really nothing you'd normally call a database. So it wouldn't scale well where you need to impose organization on a larger data set.

CON: They didn't put transactional safety into the standard. I don't think I can sleep at night with an app running that might have race conditions and then have the risk of corrupt data.

Indexed Database API

IndexedDB is basically a simple flat-file database with hierarchical key/value persistence and basic indexing.

PRO: If you're a NoSQL type of person, then this might fit the bill perfectly.

CON: Not yet available in most new browsers.

CON: If you wanted SQL, you're not getting it here. Though in the future, it might be a great building block for implementing a SQL engine for the browser.

Web SQL Database

Web Sql is basically sqlite embedded into the browser. I've used sqlite off-and-on for a few years. At first I was turned off by the name (excuse my superficiality) and by the architecture (just a flat file database). But after digging into it, I found that it's a rock solid platform, and great for production use, as long as you keep in mind its limitations. Itslimitations aren't so much size (I think you can go at least 1 GB without a problem), but inherent in flat file databases (high levels of concurrency) and missing features (stored procs and other higher-end database features).

PRO: Fast and pretty feature-rich sql implementation (besides select/insert/update/delete, you can do joins, inner selects, etc).

CON: Available in Chrome and webkit-based browsers (Safari, etc.) but not Firefox or IE.

CON: The darn W3C Working Group has put a hold on the standard since they say they want at least two independent implementations of the standard, and there's only one so far, since everybody is using sqlite.

I wish the standards group would make a special case for sqlite and approve this standard -- it's in the public domain, so it's available to everybody in the world, no strings attached. Sqlite is a perfect fit for browsers - its limitations are not problems. Only one user is using a browser at a time, so no concurrency issues. And no one wants high-end database features in a simple no-administration database. I think that's why both Android and iOS use sqlite for storage.

Bottom line

If you're only deploying on mobile platforms, then Web SQL is a no-brainer. Or if you're running on desktops and can require Chrome or Safari as your browser, then Web SQL is also for you. I wouldn't use the other two standards in any heavy-duty app at the moment.