Thank you all! Evi
On okt. 5, 01:40, DanH <danhi...@ieee.org> wrote: > > 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 <tomgib...@gmail.com> 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
