CONTACTS 

SUBJECTS
Alphabetical segments,
910103
Subject segments, 901117

0505 -
0505 -    ..
0506 - Summary/Objective
0507 -
050701 - Follow up
050702 -
050703 - I considered this at ref SDS 1.
050705 -  ..
050706 - We have three objectives to segment contact lists...
050707 -
050708 -    •  alphabetically.
050709 -    •  by subject (various fields within a record)
050710 -    •  by User
050712 -  ..
050713 - The lists themselves will work the same.
050714 -
050716 -  ..
0508 -
0509 - Subject Lists
0510 -
051001 - Should there be a Master list?  What should the criteria be to
051002 - organize lists?
051003 -
051004 - Would like to separate organizations with whom we work all the time,
051005 - from those we work with only once in awhile.  An example would be
051006 - business contacts that do not develop further.
051008 -  ..
051009 - One problem we have is how to number records created at separate
051010 - locations.  Need to avoid having the same organization identified
051011 - multiple times by different elements of the same organization.  One
051012 - way to do this would be to assign groups of numbers to different
051013 - locations.  We might do this by using dir levels, so there are no more
051014 - than 100 records in a dir.  This makes it faster to search the data
051015 - base.  Or does it?
051017 -  ..
051018 - Indexing
051019 -
051020 -   When we are searching for particular records, it is faster to get
051021 -   the record from among a list of 100 records using multiple dir's.
051022 -   When we are examining all records though for particular features, I
051023 -   guess we need an indexing system, the way we do with SDS records.
051024 -   Examine the index, get a list of records that meet the criteria, and
051025 -   get the records.
051027 -  ..
051028 - Should lists of organizations be maintained by User, so each user has
051029 - there own lists?  No because this would greatly balloon the data base.
051031 -  ..
051032 - Lets just provide this option, and let each organization work out how
051033 - it wants to do it.
051034 -
051036 -  ..
051037 - How do we identify the list separations?
051039 -  ..
051040 - It will occur in the record itself, and can be multiple.
051042 -  ..
051043 - Can separate organizations according to business type?
051045 -  ..
051046 - Are people lists maintained separately also?
051048 -  ..
051049 - Yes, there should be family/friends, business, employees
051050 -
051052 -  ..
0511 -
0512 - Dir structure
0513 -
051301 - Presently, we have:
051302 -
051303 -
051304 -             sd 09 01  -  Summaries
051305 -             sd 09 02  -  Organizations
051306 -             sd 09 03  -  People
051308 -  ..
051309 - Maybe all we do is segment the Summaries.
051311 -  ..
051312 - New model:
051313 -
051314 -     sd 09 01 UUUUU TT TTTT A-Z
051316 -  ..
051317 - User can pick only from his own stuff, or the general data base.
051319 -  ..
051320 - The first TT = Organization or people
051321 - Second  TTTT = Business type, regular, other, etc.
051323 -  ..
051324 - Maybe the records should exist separately on the disk.  I think the
051325 - accumulation of records into large files is left over from the old
051326 - version.
051328 -  ..
051329 - We do not need the Orgz number in the Summary.
051330 -
051331 -
051333 -  ..
0514 -
0515 -
0516 - Organization of data base
0517 -
051701 - Would like there to be just a single data base from which everyone
051702 - pulls the data they need.  The difficulty with this is that when a new
051703 - person arrives, or someone leaves, they would like to bring or take
051704 - there data base with them.
051706 -  ..
051707 - We could do a routine that lets Users, mark a record as belonging to
051708 - them, so they can bring or take records with them.
051709 -
051710 -
051711 -   sd 09 02 00 00 00 01
051712 -
051713 -
051714 -
051715 -
051716 -
0518 -