Q: There seem to be a lot of tables in AirVision, more than I had config files for in E-DAS / tables in ATX. Why is that?

A: AirVision utilizes a large number of static data tables instead of hard-coding certain lists and items, such as EPA codes and flags, measurement units, GSI drivers, permissions, even the models for polling different instruments directly can be updated through the database, rather than always changing the code. This offers the advantage of making many updates through simple database scripts / updates, rather than changing the code and potentially introducing errors, requiring reinstallation, etc.


Q: Why does AirVision store data in a single database, rather than using a different database for each site (as per the BAAQMD system?)

A: The rationale for BAAQMD to store data in different databases is to create some degree of resiliance in the system- that is, if a single database becomes corrupt, the data may be lost for that site, but not for all sites. On the surface, this may have some merit, but under deeper scrutiny, the drawbacks far, far outweigh any possible benefit:

• With distributed databases, data from different sites cannot be easily compared or worked with as a group. AirVision, for example, allows the user to graph ozone at all sites for a quick comparison to find outliers, and the same parameter at different sites can be compared in the Automatic Data Validation Processor. Distributing sites into different databases makes useful functions like this difficult to code or impossible to implement. The purpose of a relational database is to relate these databases together.
• Database administration (backups, archive) labor is increased by a factor of.... um, how many sites do you have? 30? 50?

It should also be noted that database corruption is a relatively infrequent event these days with modern software development tools. Agilaire's ATX system has only experienced one database issue in its history, and that resulted from the administrator removing several of the database constraints, including primary key constraints (allowing duplicate records). As designed, ATX has effectively never suffered corruption.

(The E-DAS software has on occasion seen database corruption, particular if the PC is rebooted during polling, but E-DAS uses a direct indexing/pointer operation into the file (e.g., 'go xx bytes into the file and write the data there', the "non-modern" approach). The data access layers for SQL and Oracle specifically protect against this particular kind of corruption.