We are currently Mapping our PI Point attributes using the AF Table Lookup method suggested by OSI (refer to attached document). Suggested best practice is to keep the AF Table less than 10K rows, however we are looking at having a table with >100K rows as we want to use one AF Table for all of our PI Point mapping.
Anyone who is currently using this method I would like to know if for greater than 100K rows could there be any issues with the attributes finding the tag in the lookup table in normal use? (e.g.) if we had 100K tags in there could the PI Point attributes “fail” to find the correct table lookup PI Tag string to use? Or does it cache it after the first lookup?
Also we had an idea to go one step further and host the AF Table in a SQL Server as a Database Table then use AF Table Connection to link to the SQL Database Table. Advantages of this that we could think of:
- Could create the AF Linked table across AF Databases/Servers to use the same PI Tag mapping (no need to manually maintain the lookup table inside each database/server)
- Tag list is maintained in one place
- Could expose the SQL Table to a web UI/front to enable easy maintenance/additions of tag names for end users
What are your thoughts? Have you ever heard of a similar setup being used?
Thanks in advance.