Re: related tables design

Thanks for your answer. I prefer the first solution.

> If the two tables have the same indexing style (e.g. both indexed by
> a single integer), then define one table in the normal manner:
>
> dhcpSettingsEntry OBJECT-TYPE
>      :
>      INDEX {  dhcpSettingsIndex }
>      :
>
> and then define the other table as AUGMENTing the first:
>
> dhcpIPRangeEntry OBJECT-TYPE
>      :
>      AUGMENTS {  dhcpSettingsEntry }
>      :

> If the second table has a more complex structure, then
> the indexing of this table would look like:
>
> dhcpIPRangeEntry OBJECT-TYPE
>      :
>      INDEX  {   dhcpSettingsIndex,  dhcpIPRangeIndex }
>      :

Do you mean I should use a unique index for both two tables.

In the one table scenario, I actually store all information into a linked
list.

I have a functionality to add or remove one row in the table file (I
implemented by adding an additional column, colStat, When setting it to a
specific value say 1 for adding a new row, 2 for deleting the entire row).
The question is how to I map which rows from the second table belong to
which item in the first table?

When receiving a detected snmpset on the colStat on the last node of the
linked list (last row of the table) then I can either add or remove an
entire row. Is this the right way to implement such a feature.

> The surprising thing is that you don't actually need
> to worry about this when implementing the tables.
> As long as the underlying data for the two tables is
> consistent, you can implement the tables separately.
> The underlying data is sufficient to form the linkage.

I don't understand how I can implement them separately. Neither do I have
a solution to store all information in a single linked list. Can you give
me some further explainations?

Thanks,

/Pan


-------------------------------------------------------------------------
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