FAQ

<< Click to Display Table of Contents >>

FAQ

Database Table Naming

 

Q: The database tables have the following prefixes. What do these prefixes stand for?

at_

dt_

rt_

sdt_

st_

xt_

A:

at_ - Associative Table

dt_ - Data Table

rt_ - Reference Table

sdt_ - System Data Table (Enterprise Dashboard Table). System, because it should not be touched by users; and Data, because it does change more than a regular ST_TABLE.

st_ - System Table

xt_ - Tables that support the permissions infrastructure within the EQuIS Enterprise application, and are not visible in EQuIS Professional.

 

EQuIS-Specific Database

 

Q: EQuIS requires its own database, why is this? Can the EQuIS Database not be included within another database? For example, a geodatabase?

A: The EQuIS Schema should be created within its own database/schema. The Professional application is designed to work in this scenario and QA/QC testing processes are conducted in this environment. EarthSoft does not recommend the EQuIS Schema being placed within another schema/database as functionality cannot be guaranteed.

 

With specific regard to the EQuIS for ArcGIS interface, for the interface to function as intended, the EQuIS Schema is required to import data.

 

For further information, such as the EQuIS Database Compliance Modifications Requirements, please contact support@earthsoft.com.

 

EQuIS Schemas

 

Q: Some of the stored procedures and functions are owned by two schemata, EQuIS and v54. Why are there separate schemata for the stored procedures, and why are there two schemata?

A: The v54 Schema holds report functions and procedures. The EQuIS Schema houses the functions and procedures used within EQuIS applications. Separating the EQuIS Schema provides a logical grouping of the functions/procedures. Separating the schema in SQL Server allows the schema name and package to mirror the code base used for SQL.

 

All functions and procedures can be assumed to have the EQuIS prefix. All report functions/procedures have the v54 prefix.

 

Database Level Computations

 

Q: Why are data conversion and unit conversions done at a database level? Is there a reason why the number crunching is not left at the application level for enhanced performance?

A: By design, EQuIS does computations both at the application level (.NET code), and at the database level (SQL functions). Very complex computations, in general, are better when done at the application level; however, this is not always the case. Looking up values from tables, database functions tend to out perform similar application level functions due to the database engine design and optimization for retrieving data. The conversion from one unit to another is actually a lookup as well as a computation. This operation is retrieving a conversion fact, then performs a simple computation. Database functions also allow for computed values as part of their output (without using the application level computations). For example, the database view VW_LOCATION returns values converted to an appropriate unit directly from the database, allowing for this data to be used in other EQuIS applications and interfaces.