Re: [Xlog-discussion] xlog-0.9 released

[w9ya]

On Monday 17 November 2003 10:09 am, Nate Bargmann wrote:
> * address@hidden <address@hidden> [2003 Nov 14 13:38 -0600]:
> > Well, since I brought this up, let me try asking this another way; Why
> > embed a db if you don't need to to get the same information ? I worry
> > about adding any db when it isn't needed as it takes away from the
> > simplicity I find valuable in GOOD software that is well written.
>
> I guess it depends on where the simplicity lies.  I've been able to do a
> slight bit of tinkering with SQLite over the past few days and I have
> the impression that using the SQLite library offers some sophisticated
> record keeping while allowing the Xlog code to be simply written.
>
> This is, of course, a trade-off.  Extensive searches and colation of
> data can be done by Xlog with several staticly stored search pattern
> SQL strings that are then passed to the library.  Xlog would need to
> concern itself with displaying the results rather than having to
> contrive the search algorithm and displaying the results of a flat text
> file.
>
> Of course, the simplicity of the stored log is lost as it is no longer a
> flat text file, so simplicity for the user in one respect may be lost.
> On the other hand, SQLite does seem to offer some means to avoid DB
> corruption.  Flat text files can be corrupted by bugs.  As always,
> important data should be backed up!
>
> > Or put another way, can you give me an example of how this rdbms is to be
> > used, and to what end (purpose), that I cannot also do without using a
> > rdbms ? i.e. What is missing from what we already have ?
>
> Off the top of my head here is but one example.
>
> 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.

>
> 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.

>
> > On a lighter note, I am going to be out of town at the Ft. Wayne
> > (Indiana) Hamfest starting later today. I won't be able to resume reading
> > my mail for a few days unless I don't decide to sleep. So have fun
> > discussing this.
>
> Not much has been said!  I'm tossing out my ideas for consideration.
> They are not demands by any means.  I want to learn the pros and cons of
> my ideas and if they help Joop in any way, great!  Ultimately, what
> direction Xlog takes is up to Joop and I appreciate the hard work he and
> others have put into the program thus far.

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

Very best regards;

Bob
w9ya

>
> 73, de Nate >>