FPSBASE.DOC_WHY_WE_DO_NOT_USE_KEY

>

> FPSBASE.WIP_WAFER_HIST_LOOP

View FPSADMIN.DOC_WHY_WE_DO_NOT_USE_KEY

Many databases use a key value rather than the real values for many columns which enables easy renaming. If we used a key value for tool, for example, then the column tool with the tool name would only be stored in EQP_TOOLS along with tool_key and then all other tables like WIP_EVENT_HIST and EQP_EVENT_HIST and EQP_STATUS would use tool_key. If the tool name changed, we would simply update the value in the tool column in EQP_TOOLS and that would do it. We chose not to do this for two main reasons: 1) When a tool name changes it may signify a change to the tool that could impact its speed, yield, etc. so tracking its data separately can be beneficial. If the tool moves and that's it, it could still be impacted in some way such as running less lots, running more lots of different routes, etc. It's useful to easily see this and not have it be hidden within a key value. 2) It's easier to follow what's going on and thus write queries and create reports when using actual object names instead of keys. The DWH is already complicated enough and we didn't want to add this layer of complexity to its usage. For example, you cannot just do select * from wip_event_hist if you use key values for important columns like tool and this is really frustrating. So while we made the easy choice to use real values, it's worth discussing how a tool name change affects throughput tracking. If tool A is renamed to B and the EQP_TYPE remains the same then they will show together in reports. It's useful to see the switch and then if someone really wants to backfill B with A's data it can be done, but I wouldn't want to just show B with all of the data without it being clear that B was previously A. If B changes EQP_TYPE then it is a different tool and A's data does not apply. Having the history by key would be nice since you could see the rename in the key's history, but in our case you will still see the change in the CHGLOG table even though it may show up as a delete of A and insert of B. Using a key, for each report you have to decide whether to show the name of the tool at the time the data was recorded (which would show like above) or to show the current name of the tool for all of the data (which means you have to know that all name changes will not signify an event that impacts the data for the tool).