On Wed, 20 Jul 2005 11:01:35 -0400 (EDT) Phil wrote:
PB> > Is serverProcessName declared as an IMPLICIT index?
PB>
PB> Ahh... We're getting somewhere! A question I don't understand!
PB>
PB> I didn't find anything googling for IMPLICIT indices, but when I
PB> stumbled across IMPLIED in section 7.7 of RFC1902,
Oops, yes, that's what I meant.
PB> I have one table that needs to be indexed by "user" and "organization"
PB> (the same user can exist in multiple organizations). The maximum
PB> lengths of user and organization names can exceed the 128 subid
PB> maximum, so I figure I (at least) need to index by organization Id
PB> (integer) and user name (string).
PB>
PB> There is already a table indexed by just organization, and a stable
PB> index is available (tho not currently part of the organization table).
PB>
PB> Can anyone comment on the pros and cons of how to structure/declare
PB> the tables, in particular:
PB>
PB> Whether to index the organization table by string or an integer orgIndex?
Indexing decisions are usually based on how you expect to access your data.
There is no single 'correct' way.
PB> If an integer orgIndex, should it be an auxillary object
PB> (not-accessible)? The same value will be used to index another table,
PB> does this argue for making it visible?
SMIv2 says that all indexes should be not-accessible. Whether or not it is
accessible has no bearing on whether or not it can be used for other tables.
PB> An advantage of a string indexed table would seem to be that someone
PB> could perform an order-1 lookup to find a particular organization
PB> rather than having to (bulk)walk the entire table
Exactly. You could also have a small helper table, indexed by orgIndex, to
allow for fast lookups of index to name.
PB> How to indicate on the per-user in organization (orgUserTable?) table
PB> that the organization Index (orgUserOrgIndex(?)) column corresponds
PB> to the orgIndex in orgTable (AUGMENTS doesn't seem like it's meant for
PB> this is situation)?
If the secondary table uses all the indexes of the other table, AUGMENTS is
the way to go. It if also adds more indexes, then simply list the same objects
(from the org table) in the user table, then add the additional indexes for
the second table (username). No special notation necessary.
PB> Should I just include an orgUserOrganization column to the table,
PB> so the table stands alone?
That's another option. Again, it depends on how you want to get to the data.
If this table is the only place you need it, that might make sense. If there
are more places you need to reference an org, then using the helper
orgId<>orgName mapping table might make more sense.
--
NOTE: messages sent directly to me, instead of the lists, will be deleted
unless they are requests for paid consulting services.
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-users>
You are lost in a twisty maze of little standards, all different.
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
