Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

F/OSS Flat-File Database?

Posted by kdawson on Tue May 20, 2008 05:59 PM
from the no-relation dept.
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?"
+ -
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Python? (Score:5, Informative)

    by fyngyrz (762201) * on Tuesday May 20 2008, @05:59PM (#23484234) Homepage Journal

    Can't be Java... well, how about Python?

    Here is [ideaspike.com] a completely free (PD, not GPL-style "you're free to do as we tell you") database engine that will do what you have described thus far.

    The database engine is about 19k bytes (not a typo), has no dependencies (other than Python itself), supports a useful subset of SQL so you can actually create flexible queries that produce well-sorted results from your database, and it works everywhere Python does, which is to say, it works pretty much everywhere. It's just as happy operating on a command line as it is on a web server. The results (the actual databases) are 100% portable from OS to OS. I use it on various linuxes, OS X, and Windows for tasks very similar to yours.

    Comes with tutorial examples, sample databases and extensive docs. In a 13k (not a typo) archive.

    :-)

    • Re:Python? (Score:5, Insightful)

      by maxume (22995) on Tuesday May 20 2008, @06:24PM (#23484648)
      Why not sqlite? Comes with Python 2.5 on Windows. It adds a relatively weighty 800k or so to my python installation on Windows, but the installation is dozens of megabytes overall, so it doesn't really matter.
      • Re:Python? (Score:5, Informative)

        by fyngyrz (762201) * on Tuesday May 20 2008, @06:39PM (#23484894) Homepage Journal

        Why not sqlite?

        • SQLite isn't present or compiled in, in all Python installations, 2.5 or otherwise
        • At 800k, it's about 50x the size of class dbtxt (executable)
        • Source is huge compared to class dbtxt, so maintainance is not easy
        • SQLite is considerably more difficult to use (it's also more capable, though)

        That's all I have for ya, offhand. ;-)

        • Re:Python? (Score:5, Informative)

          by dixonpete (1267776) on Tuesday May 20 2008, @07:25PM (#23485524)
          There's an add-on for Firefox that makes SQlite use fairly painless: SQLite Manager. Brilliant work.
          • 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".

            IOW, SQLite, as "lite" as it is compared to Oracle, MySQL, PostgreSQL, etc. is still overkill.

            I'm with the GP -- dbtxt looks really cool. Although, I do gotta say that OpenOffice.org would fit the bill just fine for what his requirements are: Calc can be used as a flat-file database, and I think there is support for simple CSV databases in Base.

            • Re:Python? (Score:5, Interesting)

              by legutierr (1199887) on Tuesday May 20 2008, @08:58PM (#23486440)

              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.)
          • Re:Python? (Score:5, Interesting)

            by fyngyrz (762201) * on Tuesday May 20 2008, @08:19PM (#23486108) Homepage Journal

            Having a db that is human readable can be a good thing--and a bad thing (anyone can change its contents manually?). Being small is a good thing. But even if you are doing embedded programing, is 800k such a burden that you would give up this feature set?

            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.

            OK, dbtxt looks interesting, but SQLite is very stable

            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.

    • by spookymonster (238226) on Tuesday May 20 2008, @06:25PM (#23484662)
      Just get Python, and use the version of SQLite that comes with it:

      import sqlite3
      mydb = sqlite3.connect('sample.db')
      mydb.execute("create table contacts (fname text, lname text, email text)")

      mydb.execute("insert into contacts values('Spooky','Monster','spook@spammity.spam')")

      mydb.commit()
      mydb.close()


      You can then use the free and open SQLite database browser [sourceforge.net] to browse, edit, and print your table.

      You may think you're keeping it simple by using a flat file, but you're really not. It may be somewhat easier to manually edit, but it's also easier to screw up, and I've never heard of one with the ability to undo changes.
      • by fyngyrz (762201) * on Tuesday May 20 2008, @06:50PM (#23485032) Homepage Journal

        You may think you're keeping it simple by using a flat file, but you're really not. It may be somewhat easier to manually edit, but it's also easier to screw up, and I've never heard of one with the ability to undo changes.

        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.

      • by tknd (979052) on Tuesday May 20 2008, @07:25PM (#23485528)

        He doesn't need python. He just needs a database. He can download a precompiled binary for windows [sqlite.org] that allows one to work with the database at the command line [sqlite.org]. Python is not necessary.

        And if the command line is too much, as others have noted there is already a convenient firefox extension [mozilla.org] for graphically interacting with a sqlite database.

    • Re:Python? (Score:5, Interesting)

      by goombah99 (560566) on Tuesday May 20 2008, @06:26PM (#23484682)
      You need YAML [wikipedia.org]

      I think is exactly what you are requesting.
      • Re:Python? (Score:5, Funny)

        by el americano (799629) on Tuesday May 20 2008, @06:35PM (#23484816) Homepage
        YAML is a recursive acronym for ...

        Next!

      • Re:Python? (Score:5, Interesting)

        by goombah99 (560566) on Tuesday May 20 2008, @06:42PM (#23484924)
        YAML meets the flat file requirement and can be made to be the persistent DB behind Python, Perl, Ruby.

        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? (Score:5, Insightful)

        by fyngyrz (762201) * on Tuesday May 20 2008, @06:45PM (#23484956) Homepage Journal

        Care to tell me exactly what the user of GPL software is not free to do? Otherwise maybe you'd like to retract your casual FUD-spreading aside.

        I can't legally utilize GPL'd source code within a commercial application without doing some very specific (and not always possible) things that the GPL license instructs me I must do. Any other ways I can help with your basic F/OSS education? I'll be here all day.

          • Re:Python? (Score:5, Interesting)

            by moderatorrater (1095745) on Tuesday May 20 2008, @07:02PM (#23485226)

            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? (Score:5, Informative)

          by ehrichweiss (706417) on Tuesday May 20 2008, @06:42PM (#23484928)
          Well that assertion was a massive FAIL. I make quite a living thanks to the GPL and I know tons of others who do the same.
          • Re:Python? (Score:5, Insightful)

            by aweraw (557447) * on Tuesday May 20 2008, @06:58PM (#23485168) Homepage Journal
            Mod parent up.

            IMO, the people who still, after all these years, haven't figured out how to make money with GPL software are the failures, not the GPL.

            Its just a software license; it doesn't preclude you from charing money for your work, and it doesn't mandate you make your work avaiable to the general public. I can't fathom why some seemingly intelligent people have such a hard time grasping this concept.
                    • Re:Python? (Score:5, Insightful)

                      by fyngyrz (762201) * on Tuesday May 20 2008, @08:52PM (#23486380) Homepage Journal

                      ...the licenser, who is free to refuse to fix the bugs or demand exhorbinate fees to do so. Same with new features or support.

                      To be fair, a proprietary licenser is also free to fix the bugs ASAP and well, provide such fixes for free, also to provide new features for free if they like. I do this all the time with a commercial application. A PD author also retains such freedom. These are not benefits that exclusively arrive via the GPL. And it is well to consider that with a GPL, PD or commercial application, one is free to demand money to fix something, to add features to it, to explain or teach its use, or even to simply use it. Doesn't mean you'll get it, but it doesn't mean you won't, either.

                      If you wouldn't do this to someone directly then giving code to someone else so they can do it is unethical.

                      I don't think you've really analyzed this far enough. Giving someone something, and then telling them what they can and cannot do with it, carries ethical problems in the form of imposing your will on someone else (and it also devalues the gift, in my personal opinion.)

                      "Here's a gift of a book; but you can only read it if you use LED lights." "Here's a gift of a cat; but you can only have it if you'll eat it." "Here's a gift of a some money, but you must spend it upon me."

                      You see? This is why the term "freedom" has always seemed to go so poorly with the coercive requirements that the GPL applies to the various recipients in the chain of "gifts."

        • Re:Python? (Score:5, Funny)

          by Facetious (710885) on Tuesday May 20 2008, @06:46PM (#23484968) Journal
          Great. Now I'm going to have to call Red Hat and tell them their profits aren't real. I always hate to make that call. Just last week I had to tell Steve Ballmer that chair!=discus||frisbee. He was pissed.
  • No Java? (Score:5, Insightful)

    I would have recommended HSQL, but you don't want Java. Frankly, usually, when we're talking databases I won't say "use a spreadsheet", but with 10 fields, you might as well use a spreadsheet. Of course OpenOffice.org Base is out, because it uses HSQL.

    Something like CSQL [sourceforge.net] might fit, but I have no experience with it.

    • Re:No Java? (Score:5, Insightful)

      by geekboy642 (799087) on Tuesday May 20 2008, @09:10PM (#23486560) Journal
      Mod parent up.
      This guy wants a spreadsheet, he just doesn't know it. Excel--or the free alternative from OpenOffice.org--will do everything he could possibly want, and although it saves as its own infernal file format, it exports competently into a tab or comma-delimited format.

      All the extra "requirements" are just pseudo-intellectual mumbo-jumbo that have no bearing on reality.
  • Err ... (Score:4, Informative)

    by Anonymous Coward on Tuesday May 20 2008, @06:01PM (#23484264)
    Comma Separated Variable Text Files, as exported and imported by Excel. You can get libraries to read and write these, and search these in most languages.

    Otherwise what's wrong with a simple database like MySQL or PostgreSQL on your computer?
  • OOO? (Score:5, Informative)

    by iamhigh (1252742) * on Tuesday May 20 2008, @06:02PM (#23484272)

    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
    Maybe this will do? [openoffice.org] I think it meets all your needs. You can even use it with a web app if desired. Some functionality may need Java, but most doesn't. I don't know what parts of OOO are Java-driven, but I am sure somebody here does!
    • Re:OOO? (Score:5, Insightful)

      by ADRA (37398) on Tuesday May 20 2008, @06:27PM (#23484694)
      OpenOffice uses Java for its database tool. I'm fine with it, and its probably the best choice for anyone actually wanting something simple / usefull / free, but obviously the OP is a trolling wanker, so it has to be san-Java.
  • sqlite (Score:5, Informative)

    by nguy (1207026) on Tuesday May 20 2008, @06:02PM (#23484276)
    Sqlite is used in many apps (including Firefox), it's small, and it's efficient. It also has bindings to just about every imaginable language.

    I find it amazing that you didn't come across it in Googling...
  • SQLite (Score:5, Informative)

    by kcbanner (929309) * on Tuesday May 20 2008, @06:03PM (#23484280) Homepage Journal
    Get it http://www.sqlite.org/ [sqlite.org] here.
    There are GUI clients that work fine for this sort of thing, SQL is simple for doing basic things. One file, one database.
  • how about... (Score:4, Insightful)

    by ramirez (51663) on Tuesday May 20 2008, @06:07PM (#23484366)
    a comma delimited file?

    Umm... just write a few one-liner perl scripts to get info out.
  • heh (Score:5, Funny)

    by B3ryllium (571199) on Tuesday May 20 2008, @06:08PM (#23484390) Homepage
    Since the majority of the comments so far have pointed at SQLite, I'm kind of surprised that the post didn't come "from the sqlite dept." :)
  • by bluefoxlucid (723572) on Tuesday May 20 2008, @06:09PM (#23484400) Journal
    Trying to solve such an issue as a flat file is a poor design characteristic. This says "I don't want to learn SQL" or "I want the output human readable." If you just want to store information for programmatic use, use SQLite and quit worrying about data storage format. If you want it human readable, grab libxml2 (works on Windows too) and store it as XML. Decide which problem you are solving because if you don't need (i.e. it's not helpful) it human-readable and/or want the ability to search it quickly without loading the whole thing into memory, then SQLite is probably a better solution.
  • Spreadsheet (Score:4, Informative)

    by benwb (96829) on Tuesday May 20 2008, @06:11PM (#23484418)
    Open office should do the trick.
  • SQLIte or BDB (Score:4, Informative)

    by willyhill (965620) <pr8wakNO@SPAMgmail.com> on Tuesday May 20 2008, @06:11PM (#23484424) Homepage Journal
    I'd recommend SQLite or Berkley DB. I've used BDB on a couple of projects where I needed to basically store an enormous hashtable that could be read quickly by key, and I don't think anything else comes close to the speed of that thing.

    BDB is *not* a relational database though, it's just a storage/indexing engine, which is used most notably by MySQL as a backend. SQLite on the other hand is a full file-based RDBMS with a small runtime, so it might be a bit of overkill for you in this particular scenario.

    But both of them run on Windows, Linux and the BSDs, so you won't have portability problems. And most languages have bindings for them.

  • GDBM (Score:5, Informative)

    by jschmerge (228731) on Tuesday May 20 2008, @06:13PM (#23484450) Homepage
    If you're doing simple Key,Record storing, try GDBM (or one of its analogs: DBM, NDBM). IIRC, it's included as part of glibc. The interface for it is analogous to that of a hash table... In fact there's even native Perl support for tying hash tables to GDBM.

    If that doesn't satisfy your need, take a look at Berkley DB. It offers a more sophisticated interface than DBM.

  • What about XML? (Score:4, Interesting)

    by SpinyNorman (33776) on Tuesday May 20 2008, @06:16PM (#23484496)
    A database seems overkill.

    Read the XML records into an STL container for easy access.
  • Try Metakit (Score:4, Informative)

    by kawabago (551139) on Tuesday May 20 2008, @06:26PM (#23484666)
    Metakit is a small footprint database that might fit your needs. Metakit [equi4.com]
  • by holophrastic (221104) on Tuesday May 20 2008, @06:29PM (#23484720)
    If it's just for your reference, you don't need a database at all. Databases don't become technically worth-while until you get to indexing. And until you have fifty-thousand records, or complex queries, you don't need indexing.

    So why not simply write out a tab-delimited file? Retrieval is as simple as reading every line, splitting by the delimeter, and regexp'ing whichever field you're examining. 15'000 records takes about two seconds on a modern machine. Of course, for anything more complicated, that same file gets easily imported into your favourite spreadsheet application.

    You don't need to worry about locking because you're the only one using it. And otherwise, your application simply locks the file handle, or creates & destroys a traditional lock-file.

    It's a thirty-line perl script (of legible perl). You can do it in JScript as a local HTA if you want the benefit of html etc. interfaces.
  • Why mess about with filty batchfiles, bashscripts and clunky sqlite, mysql. How about a full Oracle Database 11g Enterprise? o;)
  • I'm guessing he wants a FOSS version of FileMaker Pro; something that is an application with a GUI. All you guys are suggesting various frameworks he can use to program his own. No, I don't have an answer either, other than to suggest the spreadsheet in OpenOffice.
  • by ChrisA90278 (905188) on Tuesday May 20 2008, @07:30PM (#23485588)
    Your problem is that you are looking for a "database". This is a very complex kind of program that is total overkill for your purpose. Will you really be storing hundreds of thousands of records and wanting to do some complex querries? Ifnot why not just use a speadsheet? If you want a free spreadsheet look at OpenOffice.