Do not add custom SQL views, stored procedures, etc to your Event Chronicle, Batch Historian, or other DeltaV SQL databases....

Unless you have an air-tight plan for management of custom objects like views, stored procedures, functions, etc. for your DeltaV SQL databases, consider how a DeltaV upgrade or even a catastrophic failure and restore of the database may result in the loss of any undocumented or inadequately archived customization.

Let's look at the Event Chronicle. The Event Chronicle is made up of an Active Dataset (SQL database) to which the data is immediately being stored, and a series of Current Datasets (SQL databases), the newest of which receives a copy of the records in the Active dataset when they reach an age specified in the Event Chronicle properties dialog. 

The Active Event Chronicle data set does not get backed up; it cannot by design. The records contained within are effectively duplicated at a frequency of a high as every hour to the most recent Current chronicle data set. the Current chronicle data sets are then either manually or automatically backed up and hopefully moved to another server at a frequency specified by the system owner. 

So the data is preserved, however, any custom SQL objects or settings explicitly associated with the Active Data set SQL database are not. Unless you have implemented a SQL backup of the EJOURNAL (active) database in SQL, or have sufficiently good documentation of what was added, you are likely faced with the potential that customizations will be lost, especially during an upgrade.

If these customizations were put in place to facilitate 3rd party integration, the chance is especially increased; e.g. the integration project team from years ago wasn't asked (or didn't know) how their work would be impacted by an upgrade, and the upgrade team didn't know the integration even existed.

Rather than add the necessary custom objects for integration directly to the database, consider doing what Informetric Systems (http://www.informetric.com/) does: Add a new database of just views, stored procedures etc., that just point to the DeltaV SQL databases but do not store any data. They still have to ensure their objects work after DeltaV upgrades, (document and preserve the configuration off site, of course) but the upgrade or rebuilding of the DeltaV database does not mean they have to rebuild theirs.