Can parent tables be made volatile?
Based on the docs: Persisting tables | DataMiner Docs
It seems like parent tables with no alarming or trending enabled, falls under the criteria for being volatile.
I have two tables A and B.
'A' could be a pollable table of devices. On this table are fixed device information that does not require trending or alarming, and since everything is pollable, we do not need to save anything.
'B' is a sub-device table that has a foreign key to table 'A' and are the components that require monitoring.
'B' will not be volatile since alarming is required and contains a foreignkey targeting table 'A'.
Can table 'A' also be made volatile in this situation? Hope this example clarifies the question better.
Hi Joshua,
Table 'A' can be volatile in this situation, but you need to ensure that when the element is restarted, any rows that no longer exist in 'A' are properly removed from 'B' to maintain data integrity and avoid confusion with foreign key references.
If you want to retain device data for some time after a device is removed, it’s better to keep 'A' non-volatile. This way, users can still access the device's information even after it is no longer actively polled.
Let me know if you need further clarification!
Kind regards
Hi,
The decision to use volatile or not will always depend on the use case and how you intend to use the table.
Could you clarify your use case further?