Re: Re: Re: Re: Contained Sequences
"Dave Shield" <[email protected]>
| Newsgroups | gmane.network.net-snmp.user |
|---|---|
| Message-ID | <[email protected]> |
On 26/07/06, [email protected] wrote: > We are essentially running a proprietary radio network (hence > low-bandwidth) with each network being comprised from a number of > "stations". Egress data is queued, per-station, on a per-priority basis So the "egress data" table(s) would need to be indexed by station and (probably) by priority. > and ingress data is processed via a seperate set of queues, again, one for each > station (from which data can be received). Similarly here - the statiion ID would be (one of) the indexes for the "ingress data" table(s). > Furthermore, within a single application instance a multiple number of > radios (and hence networks) is to be supported. So you'd have a radio (or network) ID as another index for each of these tables. > I hope you can begin to see the problem... Ish... - but it still doesn't sound too unmanageable. Supposedly "scalar" objects would be in a table indexed by network ID. Per-station values would be in a table indexed by (networkID,stationID). Per-queue data would be indexed by (neworktID,stationID,queueID). etc, etc > One App, many networks, many stations, many queues..... Essentially then, a > table within a table within a table within a table.... No - a single table, with multiple indexes. Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ 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