I want to have a SNMP table with dynamic number of rows and columns.
The code which creates the OIDs in the snmpd is ready but now I'm having problems with the MIB file.
The MIB file allows dynamic number of rows(entries) but must have constant number of columns.
I'm looking for a way to solve this problem. The following solutions may be possible but I don't know if they are available on the MIB file:
The number of columns is between 1-32. If I could define the columns to be optional - it would solve my problem.
Having dynamic number of tables: If I could define Template table which will have Template name and OID, this will allow me to split my table to smaller dynamic tables with static number of columns.
Currently I can't find any record of such solutions.
SNMP does not allow a dynamic number of columns in a table. It requires that the MIB describes the table completely, so that a manager knows which columns are present, before trying to contact the agent.
Defining tables dynamically is also not permitted.
If you edit your question to describe the data you are trying to model, perhaps we could figure out whether or not it's possible to model it in a MIB. I can certainly imagine situations where the capabilities of SNMP are insufficient to model a data set. It works best where data is either scalar, a tree, or a table with a fixed set of columns.
Edit: As k1eran posted in a comment, it is possible to simply not populate some columns with data, leaving a "sparse table". Please see his comment for a link.
Related
Here's a question I'm struggling with in a star schema design.
The outline is that we track packages with embedded globally unique identifiers (tags). Each of those tags creates to a series of chronological events. I consider the events to be the facts and am including the continuously variable values as columns in the fact table. Dimensions are things like the package type.
What I'm not sure about is whether the tag identifier should be in a dimension or directly on the fact table. We've currently got over 5 million unique tags we are tracking.
Is such a large dimension advisable?
It is a degenerate dimension and you should keep this column in the fact table.
http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/degenerate-dimension/
http://www.kimballgroup.com/2003/06/design-tip-46-another-look-at-degenerate-dimensions/
I am trying to build a client to get values from an snmp enabled device using snmp4j. Using the OID and index number i can fetch the name and serial number of the device. But i heard that index number is not constant and it keeps changing.
Thou i may find the required index number (for example, of a network interface) among the SNMP OIDs, sometimes we may not completely rely on the index number always staying the same.
Index numbers may be dynamic - they may change over time and your item may stop working as a consequence.
SO i need to find a way as to how to fetch the index number dynamically. Or is there any way that i can get the serial number without hard coding the serial number.
One OID might have 150 index numbers each having an different value. i need to get a particular info from that table.
It's (unfortunately) not unusual that index numbers change. For example, some equipment will re-order some tables on reboot.
You probably already realized that if the index values are volatile, you won't be able to fetch the data in one request. But you could do it by "walking" the table.
Using the GetNextRequest, you can start at the column headers, and then proceed through the table, fetching all the data or just individual columns. For a more detailed example, see section 4.2.2.1 of RFC 1905:
https://www.rfc-editor.org/rfc/rfc1905
Assuming that there is some column in the table which will identify the correct card, you could either:
Walk only the identifying column, and from the values find the index of the card you want, then issue a single GetRequest for the serial number of that card
(More efficient) Walk both columns (identifier and serial number) by requesting those two column headers in the first request, etc. In the resulting data set, find the data for you card.
I have designed my database in such a way that One of my table contains 52 columns. All the attributes are tightly associated with the primary key attribute, So there is no scope of further Normalization.
Please let me know if same kind of situation arises and you don't want to keep so many columns in a single table, what is the other option to do that.
It is not odd in any way to have 50 columns. ERP systems often have 100+ columns in some tables.
One thing you could look into is to ensure most columns got valid default values (null, today etc). That will simplify inserts.
Also ensure your code always specifies the columns (i.e no "select *"). Any kind of future optimization will include indexes with a subset of the columns.
One approach we used once, is that you split your table into two tables. Both of these tables get the primary key of the original table. In the first table, you put your most frequently used columns and in the second table you put the lesser used columns. Generally the first one should be smaller. You now can speed up things in the first table with various indices. In our design, we even had the first table running on memory engine (RAM), since we only had reading queries. If you need to get the combination of columns from table1 and table2 you need to join both tables with the primary key.
A table with fifty-two columns is not necessarily wrong. As others have pointed out many databases have such beasts. However I would not consider ERP systems as exemplars of good data design: in my experience they tend to be rather the opposite.
Anyway, moving on!
You say this:
"All the attributes are tightly associated with the primary key
attribute"
Which means that your table is in third normal form (or perhaps BCNF). That being the case it's not true that no further normalisation is possible. Perhaps you can go to fifth normal form?
Fifth normal form is about removing join dependencies. All your columns are dependent on the primary key but there may also be dependencies between columns: e.g, there are multiple values of COL42 associated with each value of COL23. Join dependencies means that when we add a new value of COL23 we end up inserting several records, one for each value of COL42. The Wikipedia article on 5NF has a good worked example.
I admit not many people go as far as 5NF. And it might well be that even with fifty-two columns you table is already in 5NF. But it's worth checking. Because if you can break out one or two subsidiary tables you'll have improved your data model and made your main table easier to work with.
Another option is the "item-result pair" (IRP) design over the "multi-column table" MCT design, especially if you'll be adding more columns from time to time.
MCT_TABLE
---------
KEY_col(s)
Col1
Col2
Col3
...
IRP_TABLE
---------
KEY_col(s)
ITEM
VALUE
select * from IRP_TABLE;
KEY_COL ITEM VALUE
------- ---- -----
1 NAME Joe
1 AGE 44
1 WGT 202
...
IRP is a bit harder to use, but much more flexible.
I've built very large systems using the IRP design and it can perform well even for massive data. In fact it kind of behaves like a column organized DB as you only pull in the rows you need (i.e. less I/O) rather that an entire wide row when you only need a few columns (i.e. more I/O).
I have an assignment where I have two tables. Both of these two tables have multiple records that can be grouped by a certain ID creating record sets within those two tables
Those record sets can have various number of records. The trick is I have to compare those two tables and compare them by those record sets. If one record set ordered by update date (one of the record fields) doesn't find an identical record set in another table, I have to output that record set
What is the best way to do it? How do I compare two different tables by record groups/record sets/record blocks?
Should I use sub-query factoring? Should I temporary tables? Should I use something else?
Thank you very much for your generous responses and please let me know if I made my question unclear
i guess you just need a minus query to show the differences.
If you use Toad there is a specific function. Or you can use the minus operator or read this other post link
Background
I'm writing an adapter for ESE to .NET and LINQ in a Google Code project called eselinq. One important function I can't seem to figure out is how to get a list of indexes defined for a table. I need to be able to list available indexes so the LINQ part can automatically determine when indexes can be used. This will allow much more efficient plans for user queries if appropriate indexes can be found.
There are two related functions for querying index information:
JetGetTableIndexInfo - get index information by tableID
JetGetIndexInfo - get index information by tableName
These only differ in how the related table is specified (name or tableid). It sounds like these would support the function I want but all the info levels seem to require that I already have a certain index to query information for. The only exception is JET_IdxInfoCount, but that only counts how many indexes are present.
JET_IdxInfo with its JET_INDEXLIST sounds plausible but it only lists the columns on a specific index.
Alternatives
I am aware that I could get the index information another way, like annotations on .NET types corresponding to database tables, or by requiring a index mapping be provided ahead of time. I think there's enough introspection implemented to make everything else work out of the box without the user supplying extra information, except for this one function.
Another option may be to examine the system tables to find related index objects, but this is would mean depending on an undocumented interface.
To satisfy this question, I want a supported method of enumerating the indexes (just the name would be sufficient) on a table.
You are correct about JetGetTableIndexInfo and JetGetIndexInfo and JET_IdxInfo. The twist is that the data is returned in a somewhat complex: a temporary table is returned containing a row for the index and then a row for each column in the table. To just get the index names you will need to skip the column rows (the column count is given by the value of the columnidcColumn column in the first row).
For a .NET example of how to decipher this, look at the ManagedEsent project. In the MetaDataHelpers.cs file there is a method called GetIndexInfoFromIndexlist that extracts all the data from the temporary table.