FPSAPP.CHK_NAMING_CONVENTION

>

> FPSAPP.WIP_WAFER_HIST_LOOP

View FPSADMIN.CHK_NAMING_CONVENTION

This view checks that all objects are named accordingly to our agreed upon conventions: -- Underscore is the delimiter. -- First token is the application like DASH, FF, SEC, TPUT, etc -- Second token is the use of the table. Currently this is one of the following: -- P for page. All web pages query only from P tables/views (or W which are both written and read by web pages). P tables/views come from FPSINPUT, FPSBASE, B, C, and W. P tables/views must be preserved intact unless coordinated with a web page change. -- B for base. These tables/views are the link between FPSINPUT/FPSBASE and the P tables/views. All data comes from FPSINPUT/FPSBASE plus other B tables/views and is transformed as an intermediate step to load the P tables/views which are actually used by the page. We know that we can make any modifications we want to B tables/views or even delete them as long as the P views remain valid. -- C for config. C tables are also base tables and never used by pages. If we want to use the data from a C table on a page we just make a simple P view that selects from the C table. Like B, we can modify C tables as long as P views remain valid and include the same columns. -- G is for global. G tables are configuration tabls which are global to all FPS sites so the data is the same everywhere similar to FPSADMIN. The insert statements to populate G tables will be in the create script. -- W means the table is populated by a webpage. Most of the FF tables and all feedback tables are W tables since they are populated by user input on the webpage. Like P tables, W tables must be preserved intact unless coordinated with a web page change since our pages have insert/update/delete queries for these tables. Web pages are allowed to select from W tables. -- E for example. These views are an example of a query from the website that we want to store within the database so that we can test and we can ensure it remains valid. -- REF for refresh. Views used to refresh tables with ADM_TABLE_REFRESH or ADM_TABLE_MATCH procedure. For example, the REF view for DASH_B_WIP would be named DASH_REF_B_WIP. -- APD for append. Views used to append data to historical tables with the ADM_TABLE_APPEND procedure. For example, the REF view for DASH_P_H_WIP would be named DASH_APD_P_H_WIP. -- DEL for delete. DEL views are only used with the ADM_TABLE_MATCH procedure for faster delete. These views only need to know what records exist for the PK and not the values so they can be much faster. For example, WIP_DEL_LOTS_REALTIME_T just needs to know the lots and can get that from WIP_LOTS_STATIC. -- CHK for check views. These views are used to check and validate data used specifically for the application. -- APF for reports. These views are only used by APF reports. -- Third token can be H for history. We will have B_H, P_H, and W_H but we would never have C_H. We would also never have APD_H nor REF_H because the third token after APD or REF would also be B/C/W/P. -- All remaining info (starting with fourth token if third is H or third token otherwise) is the description of the table.