[08-15]

I must be missing something, but the "solution" with the 3NF and five separate tables with their own indices seems artificial and like pointless overengineering. Isn't this solved by a single index?

Or maybe a relational DB is already overengineering. Using a hash table (some libdbm lookalike) to map (ip,helo,from,to) to (time) solves the problem, too, and doesn't have a low performance failure mode.

This doesn't change the major point about everyone having been a newbie at point, though.

[nerdponx]

Are there any libdbm-style databases that support "tuples" as keys and values, instead of plain "strings"? I've felt like I wanted them in some applications, but didn't want to stringify everything.

[rudasn]

I'm not familiar with "libdbm-style databases", but CouchDB's map/reduce views allows you to emit any JS object as the key, like so

emit(key, value)

Eg

emit([0,"one"], 2)

And you can query by the value of the key.

[nerdponx]

DBM and similar databases are simple on-disk key-value stores. The use case is a lot like a SQLite, where you just need to put some data on disk and retrieve it efficiently later.

Can CouchDB be used in that fashion? Seems a lot more complicated, more like MongoDB than anything.

[rudasn]

Definitely more complicated than a key value store, or sqlite, more like a distributed document database with (optional) map/reduce views (indeces) and more recently mongo-like indeces.

Best use case though, for me, is key/value durable data storage that you can sync (two ways, no need for master).

As for performance, its pretty fast, but not redis fast as data is written on disk using btree indeces. Retrieving multiple values (documents) with similar looking keys (ids) can be quite fast.

[heavenlyblue]

You can however cache values in 3NF better down the stack (i.e. you can cache a lookup of a string to a PK and then only use PKs down the line).