I have a binary format that is effectively structured data. I currently have multiple indexes but none of them are sorted, because in my toy system ORDER BY's are not supported, an implicit ORDER BY time of record inserted exists because it is a single threaded application.
My indexing story is that I know a priori what my index will be, and I just double write them. I want to support ORDER BY on basically one additional field, and I'm having a hard time coming up with a solution that doesn't involved effectively writing on my B+Tree which has knowledge of my serialization binary format. I've thought to myself, maybe I could just store a duplicate copy of the data sorted by this field into SQLite. The data footprint is not small, but I'm willing to pay that disk cost if that's the only option. My only concern with moving to SQLite is performance design decisions that are built into a database. My system is basically only doing the work needed to iterate over my data. No concurrency, sequential reads. When/If I move to SQLite, what kind of things will I start to pay for? Concurrency? Other fluff data structure needs for SQLite? Obviously I imagine that whatever field I choose to get a sorted index on, I expose as it as a field. Then the non SQLite question: how much work would it be to duplicate a B-tree like data structure for my binary data? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
