Re: [Xlog-discussion] xlog-0.9 released

[Nate Bargmann]

* address@hidden <address@hidden> [2003 Nov 18 17:04 -0600]:
> > Due to moves in life I now have QSO data that span two calls, four
> > permanent QTHs, and numerous mobile contacts that I've noted at least my
> > transmitting county in case of QSL requests.  This is relational data
> > (at least that's how I understand it, I could be wrong) as there is at
> > least one and probably more QSOs per transmitting location.  An RDBMS
> > seems to me to be a powerful way to tie all of this together so that I
> > can do searches of my log data in a number of ways.  As I am a neophyte
> > to the ways of RDBMS, I assume that building such things as indices
> > between tables allows this magic to happen.
> 
> Again, I am asking for specifics as to what information you are looking to 
> evaluate and how ? In other words "....so that I can do searches of my log 
> data in a number of ways." is not informative as it isn't specific.

Since I'm not currently using computer logging outside of CT for the few
contests I participate in, this may still be vague.

I would like to be able to sort and print (perhaps more) the QSO data on
a "by TX QTH" basis.  There are the other common sorts of by band, mode,
callsign, date, etc.  It would be nice to be able to order this by any
arbitrary criteria (SQL is a standard language and SQLite supports a lot
of it.  Also much sorting and display work can be done outside of Xlog
through the sqlite utility.).  Again I think it's important to track the 
TX QTH so QSL and award tracking for me or the other station can be as 
accurate as possible.

> > As it is now I have to be sure to enter my transmitting location in Xlog
> > in a consistent manner so that searching the log would reveal something
> > useful.  An alternative is a seperate log file for each location, but
> > that leads to its own complexity.
> 
> I am confused. To make use of data it must be entered. I would suspect that 
> you would be required to have the xmitting location known regardless of 
> whether one used gnu tools or a rdbms.

Yes, it must be entered.  However, my understanding of an RDBMS is that
there can be a table of TX QTHs, for example, and then each QSO record
contains the primary key of the TX QTH table so each QSO record is
associated with one TX QTH.

With the flat file format the key seems to be entering consistent string 
for each TX QTH so we can search it later with grep.  If Xlog would store 
the TX QTHs and offer it as a spinbox rather than a free-form field, then 
I think the functionality would be a toss-up between an RDBMS and the flat 
file.

> Again, the question for you to answer -> Why consider this, to what end, and 
> please be specific.

It was an idea.  I brought it up for Joop's consideration.  It is solely
up to him to decide its merit.  I thought an embedded RDBMS might offer
some speed and flexibility and offer a more-or-less standard way of
working with the QSO data.  I also thought it might ease the development
work of Xlog in the future as it would not need to concern itself with
the things SQLite handles.

As I am not well versed in the classic UNIX tools, I did not think in
that direction.  I first thought of Perl to sort my log and then thought
of a DB that could do that for me or the application that uses it.

If I am way out in left field then teach me a better way.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          |  Successfully Microsoft
 Internet | address@hidden               | free since January 1998.
 Location | Bremen, Kansas USA EM19ov           |  "Debian, the choice of
  Amateur radio exams; ham radio; Linux info @  |     a GNU generation!"
             http://www.qsl.net/n0nb/           |   http://www.debian.org