> I think the main difference here is that I am not discounting alternative > approaches.
I'll admit that I overspoke slightly when I said it was "dumb" to use a DB in this case. I wouldn't say that it's smart or at all optimal, but it's not as outrageous as some other setups I've seen. But it seems a bit silly to me to be working on Android, that is so heavily (over) optimized in favor of "lightweight", and then use a database sledgehammer to kill a tiny data access fly. (Incidentally, I used a binary radix tree (a form of trie) in the project that I'm just completing on a different platform. Used it to find data (via a KWIC index) in an SQL DB, since regular searching is so awkward on a phone.) On Oct 4, 6:25 pm, Tom Gibara <[email protected]> wrote: > > There's no index "lookup" -- it's a "look-at" operation -- no > > searching. > > I didn't mean to imply that there was searching. > > And you have to write the code to build the other ways too. One way > > or another there must be logic to read the (presumably plain-text) > > source file and insert it into: > > -- An XML document > > -- An SQL row > > -- Something else > > The android SDK comes bundled with sqlite3 which includes an import command > which could help a lot (I've not used it so I couldn't say for sure). > > And with both the XML document and the SQL row you still need some > > logic on the other end to extract the data and make it "live", so no > > savings there (probably a loss). > > Not sure where XML has come into it, but as for a SQL database, yes, this > will need to be copied out of the raw resources before it can be opened and > used as such. I didn't say that a database is less work, I wanted to draw > attention to the fact that the algorithmics are only part of the effort > involved. > > In terms of dynamic update, you've got a problem in any case as to how > > you manage that atomically. Easiest is to download the new files and > > then swap them in in place of the old, a simple process, and no more > > subject to problems on a crash (actually less so) than swapping in a > > new copy of the DB. > > I anticipate that swapping out a copy of the DB would only require the > additional step of first closing it beforehand and reopening it afterwards > -- little different than closing and reopening the 'packed string' file. Of > course, with such a file, you are limited to supplying complete updates (or > at best incremental updates) to the file. A database affords more > flexibility. > > And the OP specifically framed it as a read-only data problem. > > The absence of a requirement stating that data are changeable is not the > same thing as the stated requirement that they are not. I think the main > difference here is that I am not discounting alternative approaches -- I > have used a compact frequency weighted trie to package a 250k word corpus > into an apk and I wouldn't have considered a sqlite DB for this task -- > whereas you have said it's dumb to use a database. I don't think it is > necessarily dumb, even if there are more efficient alternatives, because > applications evolve, and a database might actually be less work in the long > run. > > Tom -- You received this message because you are subscribed to the Google Groups "Android Developers" 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/android-developers?hl=en
