F/OSS Flat-File Database?

Leemeng writes "I'm looking for a simple, free, and F/OSS flat-file database program. I'm storing info about Wi-Fi access points that I come across, maybe 8-9 fields per entry. I've outgrown Notepad. This info is for my own reference only; it is not going on a Web server. Googling was unhelpful, with results skewed towards SQL, Access (MS), and Oracle, all of which would be overkill for my purposes. My criteria are: it must be simple, F/OSS, must work in Windows Vista, preferably use a portable format, must not be an online app, and must not require Java. Does such a beast exist?"

Comments

Re:Python?

[goombah99]

You need YAML

I think is exactly what you are requesting.

Re:Python?

[moderatorrater]

I'm missing your point I believe. Or being purposely obtuse which you (probably rightfully) feel you can get away with because this is a very GPL friendly forum. BSD, MIT, etc licenses allow you to do whatever you want with the code with none of the strings that the GPL has. Your false dichotomy between GPL and closed source doesn't really help promote a useful dialog about freedom of source.

Re:Python?

[legutierr]

He said he wanted a flat-file database. Why, on this Earth, would he ever need "standard SQL including joins." SQL is designed for relational databases and, in particular, joins are only EVER used in a multi-table, relational database. In fact, the guy even said "SQL is overkill". First of all, my point was that in comparison to a python-only tool like dbtxt, sqlite is probably worth the additional memory overhead of a couple hundred kilobytes.

Second, I'm not sure that you know any better than I do what the poster really needs. Open office calc might be an option, but certainly not if 800k is too much space; open office is what, like 200 megs? And dbtxt might also be an option, if doing everything in Python is what the person wants; I love Python, but there are plenty of people who don't. I'm sure that all three proposals are equally valid.

Now, to defend SQLite: in most cases, dealing with a relational database is "overkill" not because of SQL per se, but because of the fact that software needs to be installed and configured*, and because complex sets of processes need to be managed and maintained. SQLite is useful, in part, because it provides the functionality of a relational database without the complexity of the engine. Now, if you don't want or need SQL, then you might not consider that particular feature to be of particular benefit. Nonetheless, there are many situations where SQL might not be required, but where it might be useful, where in the past SQL might not have been used, but where now, because of SQLite, it will be used. There are very few cases where real-world information is not most accurately represented as relational data (in comparison to flat data). SQLite allows you to avoid making compromises regarding the way that that data is stored. And SQLite is fast.



*(Although some interpreted languages might require that sqlite's libraries be installed on a system for it to be used by a program, that is not the case for compiled languages like C, C++, Obj-C, etc., where the sqlite libraries can be compiled directly into the code distributed to end users.)