Re: 'Inter-Tables indexing' and perl

On Fri, 2005-10-14 at 11:07 +0200, Turbo Fredriksson wrote:
> Quoting Dave Shield <[email protected]>:

> > I just to check a few details.
> > Are the statistics associated with a particular system,
> > or an individual job?  (Or both?)  And is the list of
> > statistics fixed, or variable?
> 
> Ehm... Each job _ID_ (where the statistic counters is 'linked'
> to) is associated with a job _NAME_ which in turn is associated
> with a client.
> 
> So for each client ('unlimited' number of clients), there's
> 'unilimited' (dynamically named) number of jobs with 'unlimited'
> (dynamically named) number of job statistics...
> 
> So I guess one can say that the statistics is associated with
> a job _ID_...

I think we're getting tangled up in terminology here!



> >> +- client1
> >>    +- Client1_System
> >>       +- Client1_System.2005-09-13_01.05.06
> >>          +- [start date]
> >>          +- [end date]
> >>          +- [duration]
> >>          +- [files]
> >>          +- [bytes]
> >>       +- Client1_System.2005-09-14_01.05.06
> >>          +- [start date]
> >>          +- [end date]
> >>          +- [duration]
> >>          +- [files]
> >>          +- [bytes]
> >> [etc, etc for each client, each job name and each job ID]
> >
> > So for each client you have the same five statistics - yes?
> 
> Eh, no. For each job _ID_. The 'System' here is only _my_
> name of a specific job group...

Sorry - my mistake.   I'd missed that extra level of nesting.
But for each job ID, there are the same five statistics - yes?



> 
> Let's write it like this (abbreviating the stats types):
> 
>      +- client1
>      |  +- client1_job1
>      |  |  +- client1_job1_id1
>      |  |  |  +- [five stats]
>      |  |  |
>      |  |  +- client1_job1_id2
>      |  |  |  +- [five stats]
       :  :  :
>            +- client2_job3_id2
>            |  +- [five stats]
>            |
>            +- client2_job3_id3
>               +- [five stats]

But regardless of the nesting, there seem to be
the same five statistics at the bottom level.
Is that correct?



> > [per-client stats] would be represented in SNMP using a table
> >
> > 	clientSystemStatsTable
> >
> > with five columns  (cssStartDate, cssEndDate, cssDuration,
> > cssFiles, cssBytes), and indexed by the same object used
> > to index the main clientSystemTable...

> > If these (or other) statistics are actually associated with
> > a particular job, then the equivalent clientJobStatsTable
> > would be indexed by a (clientSystemIndex, clientJobIndex)
> > pair - exactly as for the main clientJobTable.
> 
> Ok, seems reasonable, but then we're back to the 'infinite'
> number of tables


No - that's due to my misreading of the nesting levels.

If the group of five stats is associated with a particular
jobID (which is associated with a particular job Name,
which is associated with a particular client), then there
are three levels of nesting going on.

So the statistics would be represented by a single table,
indexed by *three* index values (client, jobName, jobID)
Each extra level of nesting introduces another index object
to the table.

  But you only need one table (with the expected five columns)
for all the stats.



> Relieving my data, I came to THIS information instead
> (SQL translate quite good directly to SNMP) :
> 
> ClientName  JobName       JobID              [stats]
> client1     client1_job1  client1_job1_id1    .....
> client1     client1_job1  client1_job1_id2    .....
		:
> client2     client2_job3  client2_job3_id3    .....
> client2     client2_job3  client2_job3_id3    .....

Exactly!
(But see below)


> This, however, lead to a LOT of duplicate information.
> The values for the ClientName and JobName would be more
> or less the same for a whole BUNCH of lines...

No.
This list would actually be more like:

clientName   jobName    jobID
client1      job1       id1
client1      job1       id2
client1      job2       id1
  :           :          :
client2      job3       id2
client2      job3       id3


It doesn't matter if a given jobName is repeated for
different clients (or a given jobID for different
jobNames).   It's the *triplet* that is used to index
the statistics table - as long as this is unique,
everything works fine.   Just as with SQL.


Note also that clientName and jobName won't be column
objects in the stats table - they're just *index* values.
It's perfectly valid to index a table using an object
from a different table.  Index objects do not have to
be defined as part of the table that they index.
  (See HOST-RESOURCES-MIB::hrPartitionTable for an example)



> In this exact example, I have the client information
> eight times (per client) to much, and each job name
> twice (for each client).

I'm not quite sure what you mean by this.

There is inevitably a certain amount of duplication
involved in the index values from one line to the next.
But that's unavoidable - for any individual statistic
value, you've got to be able to tell which jobID
(of which jobName on which client) it relates to.

But a full walk of the 5-column statistics table ought
to look something like:

  $ snmpwalk jobIDStatsTable
  stat1.client1.job1.id1 = start date
  stat1.client1.job1.id2 = start date
  stat1.client1.job2.id1 = start date
  stat1.client1.job2.id2 = start date
	  :
  stat1.client2.job3.id3 = start date
  stat2.client1.job1.id1 = end date
  stat2.client1.job1.id2 = end date
          :
  stat5.client2.job3.id3 = bytes


So it's *only* the indexing of each OID where there's any
repetition. None of the index values need appear as
accessible columns (in any table), and there doesn't need
to be any duplication between client/name/id values.



> It would be simple though. I only need ONE table for
> the whold lot! But simplicity 'is not an option' here.
> I don't want all that duplicate information (if I can
> avoid it)...

You don't need it, if I've understood you correctly.


Dave


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users