Re: related tables design

On 17/01/2008, Xuan Pan <[email protected]> wrote:
> Thanks for your answer. I prefer the first solution.
> >      AUGMENTS {  dhcpSettingsEntry }


It's not a matter of which approach you prefer.
The question is more, which approach matches the
structure of your underlying data.

Is there a one-to-one correlation between the rows of
the two tables?   (Possibly with some gaps).

Or are there several rows in one of the tables that
relate in some way to a single row in the other?


You haven't really explained sufficiently about what
you are actually trying to do.  But your latest message
says:

>      If I set the rowStatus of the 1st row to 3.
 >     Ideally, it should delete the 1st, 3rd, and 5th rows.

which implies that several rows in the IP range table
relate to a single pool in the settings table.
Is that correct?


In which case, your data is following the second style
(a table-within-a-table),  so you need to use the second
form of MIB definition:


> > dhcpIPRangeEntry OBJECT-TYPE
> >      :
> >      INDEX  {   dhcpSettingsIndex,  dhcpIPRangeIndex }
> >      :


So all of the IP ranges that relate to testPool1 would have a
dhcpSettingsIndex value of 2 (and distinct dhcpIPRangeIndex
values).

> [DHCP settings table]
> dhcpSindex    poolName       serverIp      rowStatus
>  1         testPool           x.x.x.x             1
>  2         testPool1         x.x.x.x             1
>  4         testPool2         x.x.x.x             1

>  [IP Range Table] as augment of entries in DHCP settings table
>  ipRindex    startIp            endIp
>   3        1.1.1.1          1.1.1.2
>   5        2.2.2.2          2.2.2.3   <- newly added row
>
>  Assume row 3 and 5 belong to testPool.

In which case, walking the table would look like:

    startIp.1.3   =  1.1.1.1
    startip.1.5   =  2.2.2.2
    endIp.1.3  = 1.1.1.2
    endIp.1.5  = 2.2.2.3


You _could_ continue to use unique index values for the
ipRindex values, but it's not actually necessary.   It would
be more usual to have index values of 1 and 2 here.
  Because the table is indexed by the *pair* of
(dhcpSindex, ipRindex), then it's possible to distinguish
between      startIp.1.1    and    startIp.2.1
(even though they have the same ipRindex value).


But whether you use unique or repeating ipRindex values,
the core of this MIB is that the second (ipRange) table should
be indexed by *two* values - the first of these is what gives
you the mapping into the dhcp pools

Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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