4 of 4 people found this helpful
An MDB belongs to exactly 1 PI Data Archive, and is programmatically accessed with legacy PI SDK, which itself uses unmanaged Component Object Model code. The MDB may only access PI points on its associated PI Data Archive.
An AFDatabase belongs to 1 AF Server, and is programmatically accessed via AF SDK, which uses managed .NET code, as well as PI Web API. An AFDatabase may reference PI points belonging on different PI Data Archives.
Structure-wise the MDB is quite simple. There are PIModules. A PIModule may have child modules. A PIModule is also a container for PIAliases (references back to PI points on the associated PI Data Archive) and PIProperties (static values). Aliases and Properties are root-level only. There are no such things as child aliases or child properties.
An AFDatabase structure starts out with AFElements, which naturally can have child elements. An element is a container for AFAttributes, which can reference PI points (on different servers if needed) similar to PIAliases, or the attribute can be a static value, much like PIProperties. Note the distinction between MDB here. Tags and static values are the same type of object (AFAttribute), and you distinguish between them by examining its Data Reference, if any. And here's where it gets really different than MDB. Attributes can also be a variety of other things depending upon their Data Reference. They can be values dynamically looked up from a table, a Formula DR as a simple math expression, a value derived from an Asset Analysis, or even a custom data reference. Furthermore, AFAttributes may have child attributes, which is something MDB lacks.
For a simplistic viewpoint, MDB may be loosely thought of as being a flat-file engine, so performance peters out very quickly. Going too many modules deep quickly became sluggish. My past experience was 6 levels deep. Since an AF Server sits on top of a robust SQL Server engine, it scales much better. You can go 20 levels deep and have hundreds of thousands or even millions of elements.
While not related to structure, another big distinction between AF SDK and PI SDK is the support of Units of Measure.
1 of 1 people found this helpful
Basically, you can import your MDB structure into AF. In fact, this is part of your server upgrade procedure and you can access both structures at the same time as they are synchronized. Your MDB tools work as they did before. The MDB is only data structure, the AF is much, much more: engineering units, templates for similar elements, analyses extending PI Performance Equations, event frames replacing batches, notifications, internal or external tables, connection of non-PI data sources... All in all, well designed hierarchical database with a lot of functionality.