xlog-discussion
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xlog-discussion] xlog-0.9 released


From: Eric S. Johansson
Subject: Re: [Xlog-discussion] xlog-0.9 released
Date: Wed, 12 Nov 2003 14:20:57 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3

Nate Bargmann wrote:

* Nate Bargmann <address@hidden> [2003 Nov 11 08:55 -0600]:

Well, I think some natural keys are:

Date/time
Callsign
QTH
Locator
QSL received
QSL sent
Band/frequency
Mode
TX location/callsign

Looking at http://www.sleepycat.com/products/featurelist.shtml it
appears that a few db formats are available.

My initial thought is that the db would be a simple mirror of the flat
file format now in use.  The advantage is that the db could be
structured for easy key/value searches with, I suspect, simpler code on
Xlog.  I envision multiple log dbs still allowed as with the current
flat file format.  I'm just looking for a way to make it easier for
ordered searches to be displayed and printed from Xlog.


After reading the Berkeley DB tutorial and reference doc, I come away
thinking that there is no way to mirror what Xlog is currently doing and
enhance it with a search capability.

from: http://www.sleepycat.com/docs/ref/am/second.html

A secondary index, put simply, is a way to efficiently access records in a database (the primary) by means of some piece of information other than the usual (primary) key. In Berkeley DB, this index is simply another database whose keys are these pieces of information (the secondary keys), and whose data are the primary keys. Secondary indices can be (and often are) created manually by the application; there is no disadvantage, other than complexity, to doing so. However, when the secondary key can be mechanically derived from the primary key and datum that it points to, as is frequently the case, Berkeley DB can automatically and transparently manage secondary indices.

so pick some data to be the primary key (i.e. call sign) and then create multiple secondary keys of all the others in a way that can be managed by sleepy cat. It will be interesting to see if sleepy cat secondary indices can handle redundant keys

--- eric

It seems that Berkeley is more suited to a large amount of key/value
pairs (such as a registry), but not something like a large group of records in a table format with each record being 1 QSO with same named
keys, like an RDBMS.

I'm stumped.

I don't believe that tying Xlog to Postgres or MySQL is a particularly
good idea as it will require a tremendous amount of handholding for the
general ham population getting it set up and running correctly.

I'm fresh out of ideas...

73, de Nate >>



--
Speech recognition in use.  Incorrect endings, words, and case is
closer than it appears





reply via email to

[Prev in Thread] Current Thread [Next in Thread]