PE> Hello All!



 PE> I've been thinking about a generic interface to the messagebase, and the

 PE> possibility of using a database, and I have come to the realisation that

 PE> "area" is simply another tag.  Just like "author".



[stuff deleted]



What you say is correct. In a database the area is really just another
field. Since most accessing will be by area, it's just a matter of incluing
that field in the key. So you could have a key that had area + date written
to list out all message in an area. Others, as you suggested would include
from, to, and subject in various combinations.



 PE> Unless you want to optimize your "database" for
performance reasons of

 PE> course. Then you could use the flat files.



Actually, a database can be a lot quicker retrieving records than a flat
file. If I wanted all the messages to me, the database would find them just
by looking in its index. With the flat file, you would have to read every
message. The time when a flat file will really outstrip the database is in
adding records. Everytime you add a record to the database it must update
all the indexes as well.



 PE> So Paul, how would you like to do another one of your database tricks

 PE> on this?



What fields do you want in it?



How generic should it be - should I be able to store, say, my date of birth
without having to modify the database structure?



Are you talking just about messages or all the other things a BBS would
need that will hook into it? For example, you'd need last read pointers for
all your users. This would then mean you need a user database as well.



 PE> BTW, no-one had any complaints about your last database layout for

 PE> messages, and Rick finally gave in (he insisted that rather than just

 PE> adopting your format, I should ask on SHORTWAVE what they would like,

 PE> and the only answer I got back was a smart-alec reply!).



Does this mean he is going to use it?



 PE> Paul, did you end up using the error handling stuff in your C++

 PE> program?



Ah, well, no. I decided that the program was too slow, so I started to
change the way it worked. I haven't really touched it much for a couple of
weeks, but since I'm on holidays I probably get around to finishing it RSN.
After that I'll look at tidying it up and putting in error handling of some
sort.



 PE> And does ODBNC (open database something-or-other) have anything to offer

 PE> us here?  And is there a use for the transport layer to be in database

 PE> format, ie should the *.PKT format be different (ideally).  Perhaps in

 PE> the "standard database interchange format", which
consists of comma

 PE> separated fields, with numbers as they are, and strings in double-quotes.

 PE> I don't know what happens to imbedded double-quotes though.  BFN.



ODBC, from memory, stands for Open Database Connectivity. I don't really
know much about it.



I don't think that using comma separated values is the way to transport
data. It relies on everyone having the same format, which makes it hard to
change. This is exactly the problem that Fido is having with packet
formats. Their solution is to use kludge lines. The most flexible way would
be to have a series of fields labels and values. If you don't know how to
handle a particluar field, then you just ignore it. Something like:



MSGAREA: PUBLIC_DOMAIN

FROM: Paul Markham

FROM_ADDR: 3:711/934.1{at}fidonet

TO: Paul Edwards

DATE: 1994.02.19

TIME: 01:05:30

SUBJ: what is a message

WEATHER: Raining

ORIGIN: It's life Jim, but not as we know it

TEXT: nothing in here except message text



Fields should be able to occur in almost any order. You'll need some way to
determine the end of a message. You could always say that TEXT is the last
field, you could have and end of message tag, or you could have a field
count at the beginning.



BTW, storing the above in the database isn't too hard, although you'd
probably want to use a query language such as SQL to extract the info.





Paul



--- GoldED/2 2.42.G1114