Note:This topic was updated for 9.3.1.
Various alternatives exist. Users can persist this higher-level logic in a number of ways. For example, the logic could be implemented as:
Stored procedures and database triggers in the DBMS
Extended types in the DBMS
A separate application tier that works on the rows and column types in tables
Countless DBMS implementations over the past two decades have demonstrated overwhelmingly that the use of an application tier is appropriate for advanced applications. For example, all the widely-adopted customer information systems (CIS), enterprise resource planning (ERP) systems, and accounting packages implement advanced application logic in the application tier, which enables more openness and extensibility, higher performance, richer toolsets, and increased flexibility.
Users interact with and perform transactions within these systems through the application logic for the vast majority of operations, and only use SQL for focused (and appropriate) activities.
Separating the application logic above the data tier also allows the same logic to be applied to DBMSs, files, XML, and other data storage alternatives. This enables this architecture to be more open. For example, the geodatabase application logic in ArcGIS is also used to read and work with all geographic data sources—CAD data, shapefiles, MapInfo data, Intergraph GeoMedia files, GML files, and so forth.
