Is SQLite the only option for data storage in a cross-platform desktop app? WTF?
SQL is such a broken leaky abstraction and most NoSQL stuff is even worse (JSON for queries? Seriously?). Either way though none of that helps desktop apps unless you want to manage a separate database process.
I'm tempted to write my own B+tree impl but that's like a pain in the ass. Where is libpersistent-data-structures that I can drop into my project?
SQL is not a "broken leaky abstraction". SQLite is good, just use it. If you hate that and you hate NoSQL, then yes, you need to write your own. You answered your own question.
>>2
You lose compile-time checks and it's more verbose (with prepared statements). Then you get the query optimizer that just adds uncertainty to whether it will optimize the query correctly (rewriting queries to get the optimizer to do the right thing?).
I don't hate NoSQL, but I don't know of any NoSQL databases that get it right.
>>4
There are still a lot of file systems that don't like having millions of small files dumped on them (think 100x overhead). With a real data structure, I could store more than one piece of data per file and still be able to do fast lookups.
>>1 if you're too fucking stupid for sql just write it down on paper or speak it into your iphone faggot op
Name:
Anonymous2013-01-21 11:15
xml.. ?
Name:
Anonymous2013-01-21 11:26
Meh, why bother, soon RAM and SSDs will merge into one, all programs will have persistent state, DBs will be redundant code.
Name:
Anonymous2013-01-21 14:17
>>11
That's a great fucking idea! Sure sounds secure!
Name:
Anonymous2013-01-21 14:27
>>10
There's too much data to load it all into memory (with acceptable performance on modern consumer-grade hardware). Every lookup would require every parsing the whole file.
Name:
Anonymous2013-01-21 16:27
The SQL part of SQLite is a minor nit, you get in exchange relational'ish data access, plausible ACID properties, the most liberal license ever available, well tested and documented ANSI C code and drh's holy blessing. In a C program it effectively becomes like a scripting language. What are you looking for in particular? What are you willing to take out and what you need to keep? You could use something like cdb I guess.
NoSQL stuff are for the most part glorified key value stores that are sprouting out of nowhere because the ORM shit in rails doesn't mesh with anything in reality. I'd make an exception for some like CouchDB, which sports a sync feature for disconnected operation, I'd like to check that out some day.
Name:
Anonymous2013-01-21 17:01
Just use hierarchical filesystems. For anything more complex than that, use BigTable.
http://www.sqlite.org/queryplanner.html The best feature of SQL (in all its implementations, not just SQLite) is that it is a declarative language, not a procedural language. When programming in SQL you tell the system what you want to compute, not how to compute it.
I've heard this again and again but if it worked like that, every mainstream programming language would be declarative. Machines are great at optimizing code that isn't performance critical (application logic), but become more and more annoying the more you try to tune them.
And then, without the query planner, the whole database illusion melts away because you need to know the performance characteristics of the real data structures used (but you need to know that anyway).
I agree with you about ORM shit and key-value stores are exactly what flat files are good at.
cdb: I respect djb's work but I don't think I can make a "constant" database fit (I need to append/modify)
Berkley DB: key-value API, but I'll look closer since it claims "btree storage"
>>18
Write some bigger apps and then get back to me.
>>19
Write some smaller apps and then get back to me.
>>39
Assuming each of the chinamen can store at least the address of two other chinamen, n bytes can be stored with only something like O(2n) memorizers, unless I'm mistaken. At this point, you might as well get byzantine to handle when your memorizers die or quit or go on strike or something. In the long run, this hurts you, but at least you can get 30x the storage per byte, so that will keep your coefficient down.
Think of chineses as memory pages. You can now sort them in any order (by name, by birth datetime, you name it, just watch out for collisions!) to obtain a chinese address space.
Then you just map your address space to the chinese address space. MAX_BYTES_TO_MEMORIZE_BY_A_CHINESE constant will be of help, but obtaining its value is left as an excercise for the reader.
Name:
Anonymous2013-05-15 7:26
>>45
Thing is MAX_BYTES_TO_MEMORIZE_BY_A_CHINESE is variable, though that increases complexity and depending on the amount of variance might not be worth the extra storage space. Further investigation is recommended.