I’m an embedded guy, not a database guy. I’ve been asked to redesign an existing system which has bottlenecks in several places.
The embedded device is based around an ARM 9 processor running at 220mHz.
There should be a database of 50k entries (may increase to 250k) each with 1k of data (max 8 filed). That’s approximate – I can try to get more precise figures if necessary.
They are currently using SqlLite 2 and planning to move to SqlLite 3.
Without starting a flame war – I am a complete d/b newbie just seeking advice – is that the “best” decision? I realize that this might be a “how long is a piece of string?” question, but any pointers woudl be greatly welcomed. I don’t mind doing a lot of reading & research, but just hoped that you could get me off to a flying start. Thanks.
p.s Again, a total rewrite, might not even stick with embedded Linux, but switch to eCos, don’t worry too much about one time conversion between d/b formats. Oh, and accesses should be infrequent, at most one every few seconds.
edit: ok, it seems they have 30k entries (may reach 100k or more) of only 5 or 6 fields each, but at least 3 of them can be a search key for a record. They are toying with “having no d/b at all, since the data are so simple”, but it seems to me that with multiple keys, we couldn’t use fancy stuff like a quicksort() type search (recursive, binary search). Any thoughts on “no d/b”, just data-structures?
Btw, one key is 800k – not sure how well SqlLite handles that (maybe with “no d/b” I have to hash that 800k to something smaller?)
Also SQLite is the Database chosen by virtually all mobile operating systems. Android, Iphone OS and Symbian ship with SQLite which makes me think that manpower was spent to optimize it for the processor in those phones (nearly always ARM).