RE: [Xlog-discussion] xlog-0.9 released

[T + J Williams]

Hi Guys

I have also tried mysql and sqlite against my log file.  Both work
great.  Sqlite seems to be the easiest of the two to install.  But, I do
still wonder about a new linux user getting a db installed and working.


I still haven't seen where multiple tables would be needed yet.  It
might be faster than searching one long table, but is a logfile really
that long?!  Also, adding a new QSO would require updates several
tables.

In favor of the DB, the SQL statements do not have to be "static".  A
GUI screen can easily make the user specify all the fields needed to
have the program dynamically build a valid SQL statement.

I still like the flat file, but watch out.  A grep for 20 may find a 20
meter qso's and a report of 20 over S9.  You may want to consider "sed"
for this

73,
Ted - wa0eir
 


> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden 
> On Behalf Of Nate Bargmann
> Sent: Tuesday, November 18, 2003 7:16 PM
> To: xlog-discussion
> Subject: Re: [Xlog-discussion] xlog-0.9 released
> 
> 
> * 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


_______________________________________________
Xlog-discussion mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/xlog-discussion