F/OSS Flat-File Database? 702
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?"
Perl DBFile (Score:3, Interesting)
Easy, fast, simple.
Uhh (Score:3, Interesting)
If you are just doing tabulated data in a piece meal form, Excel with an Access back-end will do the trick, I'd be willing to be you're going to be able to find templates that help you start. You could also use File-maker (which is overkill, but easy to use) and go to the user community for starting templates.
A CSV File? (Score:3, Interesting)
Depends what you want to be able to do with your data? If it's just quick searches to find local wifi points then it seems overkill to use a multi-platform/FOSS database
What about XML? (Score:4, Interesting)
Read the XML records into an STL container for easy access.
Re:Python? (Score:5, Interesting)
I think is exactly what you are requesting.
Re:Python? (Score:2, Interesting)
Re:Wikis on a Stick (Score:3, Interesting)
Re:Python? (Score:5, Interesting)
If it were not for the Flat File requirement then a simple Python shelve or Perl Tie would be the most logical solution since they are both part of the standard library so don't require installing libs on random computers you might use or port to.
of those two Perl Tie is probably the most suited because it's backed by a real DB operating off the disk not fully in memory.
But why not do both: use YAML as the DB backing the Perl Tie.
then you get a nice human readable flat file.
Re:Python comes with SQLite (Score:5, Interesting)
Class dbtxt includes the ability to undo changes, and features human-readbility for the flat database files. It's trivial and not error-prone at all to mod a database file to delete, or undelete a record, and of course you can do it through the database engine as well.
Re:Python? (Score:5, Interesting)
Re:Python comes with SQLite (Score:4, Interesting)
set first "Spooky"
set last "Monster"
set email "spook@spammity.spam"
# In practice it's really easy to put values into variables
mydb eval {insert into contacts values (:first,:last,:email)}
The advantage? That code is now totally armour-plated against SQL injection attacks as well as being fast. Which is nice, really really nice.
Kexi (Score:3, Interesting)
http://www.kexi-project.org/ [kexi-project.org]
You really do NOT want a DBMS, use a spread sheet. (Score:5, Interesting)
Re:Python? (Score:3, Interesting)
Did I say it was unreasonable? It's your code, you're free to put any conditions you want on it. I encourage you to do so. PD, GPL, BSD, commercial, etc., that's your call. With these choices come consequences to the end users of the application and/or the source code, though, and there's no squirming out of them.
What I said was that the GPL imposes "you're free to do as we tell you" conditions while holding up PD in contrast. Which is precisely accurate. PD doesn't impose such conditions; hence PD is a feature offered as compared to any GPL'd alternative. Since it is a feature that directly improves usability and lightens the conditions under which the user can sell, modify and redistribute the source code, I find it well worth mentioning.
Re:Python? (Score:3, Interesting)
Just because you don't necessarily want/need to make it public doesn't mean you want to distribute it as binary-only or not be able to use other GPL code in the development or expand it in unforeseen ways in the future.
I'm not a programmer, but in one of my past jobs I used to hire developers for projects. One of the caveats I applied to everything we did was that it had to be GPLed, partly for flexibility down the line if we needed to modify it or distribute it to partners (gov't and universities), but also because the nature of the work was such that 95% of the foundations already existed in other GPL projects, all we needed was customization to our particular workflow. It's no secret that a lot of free software is only usable by techs, and much of what I was doing was developing user-friendly interfaces for our employees, and then paying to have the backend made functional.
But we never had the software available for the public, just because they'd have little interest in it as it was so customized for our particular use and I'm sure some of the very situation-specific code was fairly hacky. I know the developers did push patches upstream when it made sense, and I encouraged them to do so and even paid for more hours here and there to make sure the code was clean enough to do that. I strongly suspect that most developers who make a living with GPL/BSD software (other than employees of Red Hat and Mozilla and the like) pay their rent on projects like this. It's a great symbiotic relationship between the GPL software community and private enterprise.
Re:Python? (Score:3, Interesting)
Re:Python? (Score:4, Interesting)
Even if you don't end up using it for this particular app, it definitely deserves a look. Although it'll never displace XML, it definitely answers at least some of the questions XML attempts to answer, reduces "tag bloat," and is easy on the eyes.
firebird db (Score:1, Interesting)
Re:Python? (Score:5, Interesting)
Sure, it can be. For instance, adding 800k of stuff to your application means that you are giving up control. You might have the source (which is going to be somewhat larger in this case)... but do you have the time to dig into it if there's a problem? Does reporting the problem necessarily mean it's even going to get fixed? For instance, I've reported many problems to various authors, some of which got fixed, some didn't. Likewise, adding a feature can be non-trivial with a large (source code) project. Compare that to a very lightweight thing that, let's say, almost does what you want but you just need feature X. Might be a whole lot easier to add that to a 20k "almost-there" set of source than megabytes of source, is that not possible?
Distribution of a class module with a python app is an entirely trivial thing to do. For that matter, you can take the class and put it in the same file with your application if that appeals, giving you the advantages of atomic distribution -- harder for an end-user to separate things and make whole app, as you handed it to them, fail to work.
And I suppose the elephant in the room is that the end user may have no need for the features. I sell a commercial program with features not available in other programs in the same general application space, functionality-wise; that doesn't mean it will sell to anyone on that basis unless they actually need those features, right? In this specific case, based on the article, the needs described seemed to be met by what I'd written, and hence my post.
PostgreSQL whips the living hoo-ha out of SQLite; it is larger, but offers more features (sound familiar?) Yet SQLite has a place, as your advocacy clearly indicates. I would venture that the difference between SQLite and class dbtext is similar, just occupies another place on the size/features scale. In the end, the user, based on their requirements, may go "what a POS" and step up the ladder. From either one.
dbtxt also seems to be very stable. It's never failed for me, nor have I ever received any indication that it wasn't doing what it was supposed to do when used as indicated. Also -- as a user myself -- I'm quite interested in fixing it, should it turn out to have problems.
Also, just as an aside, If someone can explain cross-platform file locking in python to me in terms I can understand, and if python's ability to lock can be made to implement a reasonable form of "wait for lock to release", I'd like to add that as a feature, too. I found python's docs on locking to be more than a little opaque. I'm sure it's just me.
Re:Python? (Score:5, Interesting)
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.)
Re:Python? (Score:3, Interesting)
There is a philosophical position that I think is important. The term "share and share alike" is something that most kids have learned in childhood for centuries for the greater good of society. The GPL simply puts that in the license.
I am a capitalist, seriously, I honestly think that real people deserve real compensation for their work. Actually, let me rephrase that, people have the right to try to get compensation for their work.
The BSD license makes no philosophical statement, and that is sad. I honestly believe that if you put your code out there for someone to use you should try to get something for it. Your life, the time you spend writing the code, is valuable. Make it worth something.
Would TextDB or BerkeleyDB serve ur purpose? (Score:2, Interesting)
Re:Python? (Score:3, Interesting)
select * from roles r1, roles r2, roles r3, roles r4, roles r5, roles r6 where r1.costar=r2.actor and r2.costar=r3.actor and r3.costar=r4.actor and r4.costar=r5.actor and r5.costar=r6.actor and r6.name='Kevin Bacon";
Not Free but Cheap (Score:3, Interesting)
I like notetab a lot, wish he'd port it over to Linux...
Firebird RDBMS (Score:1, Interesting)
Accurate and very full SQL implementation, fully transactional and ACID compliant, stores everything on disk in a single file, and can be archived in a transportable format for restoring on different OS/Architectures.