PE> One of those rare moments when I actually said something you agreed with!

 PE> :-)



 No, the sky hasn't fallen down yet :-)



 PE> What I meant was flat files like Squish has, where there is an index.  I

 PE> wouldn't have any more indexes than Squish has, to stop any complaints

 PE> about speed.



Well, personally I consider a flat file to have no indexes.



 PM>> What fields do you want in it?



 PE> Whatever has been deemed necessary/desirable by all the current formats.



There are a couple of approaches. You can store every field on the one
records, which makes it quicker and easier to find, but not very flexible
to add fields to it.



Each field can be stored as a separate record. This allows any number of
fields to be stored for each record and extra fields can be added without
any hassles. It is, however, slower and more difficult to retrieve the
data.



The other approach is to combine the two. Include all the mandatory fields
in one record and the fields that don't occur as often in separate records.
This is probably the closest to the current approach with *.PKT and Squish.



The best approach will depend on how the data is going to be stored and queried.



 PM>> How generic should it be - should I be able to store, say, my date of

 PM>> birth without having to modify the database structure?



 PE> I'm not really sure.  Say for example everyone's name was a unique

 PE> character string.  Then that could be mapped onto a particular "person

 PE> number", and then all the details could be added there.  However,

 PE> obviously for performance reasons, you would never actually do a lookup

 PE> to create the link, or even create the "person details"
table in the

 PE> first place.  What I'm more interested in is getting the logical schema

 PE> right, and then the actual implementation would be either 1) a genuine

 PE> simple database or 2) squish/jam/etc format, made to look like a

 PE> database.



 PE> However, everyone's name is not a unique character string, but there's

 PE> nothing stopping a "world database" of people's names,
and a ^A kludge

 PE> line which says "WORLDDB_FROM: 2777666555" in it at a
later stage.  The

 PE> fact is, there may be some way of mapping to unique numbers.  E.g. you

 PE> may just decide that everyone with a name of "Paul
Markham" goes to

 PE> unique number 2777666555, which as far as anyone in Fidonet knows, is a

 PE> non-dupe mapping currently, so is an acceptable short-term compromise.



I think there are two issues here. One is how the messages are to be stored
in a database, the other is how to transport the messages. One of the
principle behind database design is to make sure that data is only stored
in one place. This means that you could have user table where each user has
a unique number and that number is stored in the message file for the
'from' and 'to' fields.



On the other hand, when you're transporting mail you want each message to
be self contained.



 PM>> Are you talking just about messages or all the other things a BBS would

 PM>> need that will hook into it? For example, you'd need last read pointers

 PM>> for all your users. This would then mean you need a user database as

 PM>> well.



 PE> For starters, just messages.



 PM>> Ah, well, no. I decided that the program was too slow, so I started to

 PM>> change the way it worked. I haven't really touched it much for a couple

 PM>> of weeks, but since I'm on holidays I probably get around to finishing

 PM>> it RSN. After that I'll look at tidying it up and putting in error

 PM>> handling of some sort.



 PE> Too slow?  How long did it take to run?



I don't remember exactly, but it was really thrashing the hard disk.



 PE> The format looks good.  Although if that's the case, what's wrong with

 PE> kludge lines, as they're virtually identical.



There's nothing really wrong with kludge lines, except that they shouldn't
be part of the message text. The same goes for the area tag and the origin
line.



 PE> About the "Weather".  How do you know whether this should
be a character

 PE> string or whether it should be a number, where 1=raining, 2=sunny,

 PE> 3=hail.



If you've only got a limited number of choices then you can replace it with
some sort of code. If the choices are unlimited then you need to include
the whole text value.



 PM>> Fields should be able to occur in almost any order. You'll need some way

 PM>> to determine the end of a message. You could always say that TEXT is the

 PM>> last field, you could have and end of message tag, or you could have a

 PM>> field count at the beginning.



 PE> What do you suggest?



Dunno.



 PM>> BTW, storing the above in the database isn't too hard, although you'd

 PM>> probably want to use a query language such as SQL to extract the info.



 PE> Remember that there are 2 options, the database way and the squish way.

 PE> Actually, with PQWK190 out, I expect I will be able to bludgeon the rest

 PE> of the QWKers over to being points, and get rid of all my message areas,

 PE> which will get rid of having to make sure I use a format (ie squish)

 PE> which my BBS can use. Then I would be able to use a proper database,

 PE> instead of kludging around with flat files.  Actually, that would be

 PE> nice.



You'll still need some sort of message base to store your messages in. This
then requires a message editor and mail processor that can read that
format.



 PE> Now the fact is that squish is just a stripped-down, not very flexible,

 PE> database.  I could make an SQL parser that works with the squish

 PE> database, if need be.



Yes squish is just a database, and yes you could write some sort of SQL
processor if you want. However, you'd have to know SQL first!



 PE> However, before I get into writing SQL parsers (actually I can probably

 PE> just manually do the SQL parsing), what would you suggest I use for a

 PE> database? Something that I can write C with embedded SQL in.  Actually,

 PE> this manual SQL parsing sounds pretty nifty, because this bit should be

 PE> pretty small, so I think I'll write the CSQL, and then translate it into

 PE> Squish MSGAPI calls. Sounds good!  BFN.



Not really sure what you mean by 'manually parsing' the SQL.





Paul



--- GoldED/2 2.42.G1114