Changes between Version 11 and Version 12 of BluePrintRegionsAndIncidents
- Timestamp:
- 02/18/11 08:41:46 (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
BluePrintRegionsAndIncidents
v11 v12 115 115 116 116 ==== Use relationship tables ==== 117 Many types of things are associated with an incident. The "relational" way to do this, without adding fields to entities, is to add relationship tables that associate an incident with each of the types. That is, there would be an "incident assessments" table that says which assessments go with which incident, and so-on for the other associated types. This allows overlap. When an entity is no longer needed for an incident, it's relationship can be deleted or "expired" by setting an end date.117 Many types of entities are associated with an incident. The "relational" way to tell which entities go with which incidents, without adding fields to entities, is to use relationship tables that associate an incident with each of the types. That is, there could be an "incident assessment" table in which each record has a foreign key reference to an incident and to an assessment, and so-on for the other associated types. This allows overlap between incidents -- one entity can be associated with more than one incident. Additional data can be included in the relationship tables, such as a start date and end date. When an entity is no longer needed for an incident, it's relationship can be deleted or "expired" by setting an end date. 118 118 119 (If a "paper trail" is needed, i.e. a record of what was used for each incident, there are several ways of providing that. One is to add start and end dates to the relationship. Since those could clutter the table, one could dump / pickle historical data, or move them to a parallel set of "expired" relationship tables. Keeping it online would be more convenient for preparing reports. Simplest is to leave them in the main incident relationship tables but set their end dates.) 119 If a "paper trail" is needed, i.e. a record of what was used for each incident, and when, or who worked on it, and when, there are several ways of providing that. One is to add start and end dates to the relationship tables. If someone / something stops being associated with an incident, its end date is set. If that person / resource later comes back to the incident, a new relationship record is created. (Think of keeping a log of hours worked on each of several consulting projects -- a simple way is to record start and end times for each work session.) Since those old records could clutter the table over time, and slow access, one could dump / pickle historical data, or move it to a parallel set of "expired" relationship tables. Keeping it online would be more convenient for preparing reports. Simplest is to leave them in the main incident relationship tables but set their end dates. 120 120 121 121 ----