Ability to manage multiple temporally sequential databases from a single historian

[davidraker]

It is not uncommon for databases to become fragmented, over time, for instance due to filling space on a particular server, or choosing to use a different database engine for new data. This creates problems, later on, when querying data, since portions of the data corresponding to different time ranges are now stored in separate databases.

The historian should be able to manage a set of sequential data stores and return queries transparently which cross the date boundary separating these. An example:

• On January 1, 2022, a new database was created on a new server due to lack of space on the existing server.
• On January 1, 2023, a new database was created using a table type with better performance.
• A query is made spanning the date range from Dec. 2021 to Jan 2024.
• The historian detects, from configuration, that there are three separate datastores for this date range, and makes three queries -- one to each database.
• The historian returns records transparently to the user as if they had all came from the same datastore.

Alternatives:

• Separate historians for each database: This means that multiple agents must be running to make queries, only one of which is collecting new data. Additionally, the user must make the queries separately for each set of data. The user must keep track of which historian contains which range of dates.
• The databases are queried directly without using any historians: This has the same disadvantages as separate historians, though it may always be preferable for some users since the native query language of the databases is likely to be more featureful than the historian query mechanism. Where that is the case, there will not be an advantage from this feature request.