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.
