PM>> Area Table

 PM>> -+--+--+--

 PM>> Area ID

 PM>> Area Name

 PM>> anything else you can think of like security, retention etc.



 PE> I think this should really be an "attribute" table, don't
you?  And the

 PE> security should be just another attribute, no?  BFN.



What generally happens is that during design you identify all the
attributes you need and they just become fields in the relevant tables. In
the case of the security attribute, we are assuming that it is something
simple such as the minimum user level required to access the area and hence
can be represented with a single numeric field. If it wasn't then you'd
create a security table for it and put the security ID in the area table.



In the above case we are defining a file area, so all or its attributes
belong in the file area table.



If we were trying to store the message format I was suggesting, then the
design considerations are different. In this case we don't know all the
fields that will appear and, assuming we want to store them all
individually, you have to have something like:



    message ID

    Field Name

    Field Value



Which would look like



    ID    Field Name    Field Value

    --    ----------    -------------

     1    AREA          PUBLIC_DOMAIN

     1    FROM          Paul Markham

     1    TO            Paul Edwards

     1    SUBJECT       file database



This makes it harder to query the table to, say, find all the records I've
entered in PUBLIC_DOMAIN.



It can also waste a lot of space. Most databases only allow fixed length
fields, so for the value you'd have to allow the maximum. Most PC database
allow memo fields which are variable length, but they can't be indexed.





Paul



--- GoldED/2 2.42.G1114