Is there a simple key-value database for use in scripts and such? No authentication, no schema, no nothing - just

name <file.db> [get|put] <key>

and in reads/prints value to stdin. Yes, there are hundreds of ways, it can even be done using nothing but grep, but I have a strong aversion to reinventing the wheel and wouldn't mind a decent performance so before I do it using sqlite (which is not key-value at all but happens to be installed) I decided to ask if there is a ready-made solution.

miller allows you to work with key-value format among others. Generally speaking, there's a ton of tools that work with structured text formats (CSV, XML, JSON, YAML, whatever). And even if grep-dctrl is supposed to be used with Debian control files, I guess it could be repurposed to work with arbitrary data in similar format (sort of generalized RFC 5322).

A more comprehensive solution would be something like Fsdb or GNU Recutils.

As I said, I'd like to have reasonable performance, and text-based stores usually have horrible update speeds. I found gdbmtool - looks like just what I needed.

scripts are slow (including bash). How much data do you want to handle at all?

Any database format, text or otherwise, has speed dependent upon the amount of data required (and stored). For a simple key/value pair, even 100+ entries in text format can be accessed in linear format with insignificant delay.

As the database grows then different tools are needed to provide faster (usually indexed) access.

Depending upon your needs you will need to select the best tools and ease of config. Having any form of database server running for a tiny database and infrequent access is a significant waste of cpu time and often config effort.

1 members found this post helpful.

In the earliest days, these were called "ISAM files" or "VSAM files." They stored and retrieved values based on a single key.

Some languages still directly support indexed files. The Perl language, for instance, can "tie" what appears to be "a hash" to an underlying physical-file representation.

Today, probably the closest technology is SQLite, which is a public domain(!) database system which is entirely based on "a 'database' is a 'single file.'" There is no "server."

>> The only thing that you need to be aware of, when you are updating these files, is the importance of using "transactions." Without this, SQLite will not use "lazy writes." Begin a transaction, insert or change a block of records, then commit.

1 members found this post helpful.