Scott, Localstorage and sessionstorage are not designed to hold large amounts of data or to do high performance work with data. They are designed for simple access to small bits of data. If you try to use them as an alternative to SQLite, you will most likely run into performance issues and storage size issues.
For instance, on the iPhone implementation, if memory serves, the performance characteristics of localstorage are such that each set() and get() are run in a separate SQL transaction under-the-hood (on the iPhone, they are actually implemented with SQLite -- they just expose a simpler no-SQL API). This kills performance when you're getting or setting a bunch of items at a time (think the initial sync) or searching through a bunch of items. Plus, these APIs are *synchronous* (SQLite is an async API), so the phone's browser locks up while you're doing a bunch of get()s or set()s -- not exactly a pleasant experience for the user, you can't even show a spinning gif while the DB operation is taking place. Also, there is no way to increase the max limit of localStorage on the iPhone. Once you hit the limit, you just get errors -- there's no request that pops up to the user, requesting to increase the size (as there is with SQLite). --- Not that the RDBMS vs. non-RDBMS question isn't valid... the non-RDBMS won the day in the standards (SQLite is non-standard, it was proposed as a web standard by Google and Apple, but was blocked by Mozilla and Microsoft. The web standard that won the day is the IndexedDB API, which Mozilla is implementing and some webkit branches have already implemented: http://hacks.mozilla.org/2010/06/comparing-indexeddb-and-webdatabase/, http://www.w3.org/TR/IndexedDB/). So if you want to compare apples with apples (powerful, performant client-side data solutions) the real alternative to SQLite is IndexedDB. But since IndexedDB isn't on any non-beta browsers yet, it's hard to think of it as "real". If you're trying to build an app that will be actively developed for the next 5-10 years, I would encourage you to use SQLite, but to use it in a key-value-pair-with-indexes way, so that it will be isomorphic to convert it to the IndexedDB standard, if/when the standard is implemented and supported. This means avoiding JOINs and keeping the SQL layer simple (one table per entity, ideally with a key column and a value column that contains JSON, and any fields that need to be searchable would be separate columns that could easily be converted to indexes in an IndexedDB approach). -- peter rust -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of KCL Sent: Thursday, November 04, 2010 8:52 AM To: iPhoneWebDev Subject: To RDBMS or not to RDBMS, that is the question... OK. So the debate has been raging--flat key-value (localstorage/ sessionstorage) vs. RDBMS (SQLite) for this project. The truth of the matter is that we don't need an RDBMS for what we're doing. Data is loaded from the server initially into the app and pretty much just updated by the user and loaded back to the server when available. The key reason for the storage is to ensure no user-entered data is ever lost. On the surface, SQLite seems like overkill. However, when I started concepting the solution, I kept coming to naming conventions to keep the data organized and grouped for easy maintenance--that would require me to parse the variable names and such. Which felt like I was building tables! So, why wasn't I using the DB again? So I started to question some basic assumptions: Is SQLite truly loaded and part of the browser, regardless of if it is used? Is "localstorage" faster for simple transactions? Is there significant overhead, processor-wise when using SQLite vs. localstorage? Just how much storage overhead is there between the two? We can deal with maintaining the SQL code as anyone supporting our application will be well-versed in SQL and it may actually *help* to have something familiar in the code for anyone who might be doing maintenance in the future. Thoughts? Scott -- You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en. -- You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en.
