Changes between Version 5 and Version 6 of BluePrintRegionsAndIncidents


Ignore:
Timestamp:
02/16/11 14:47:14 (11 years ago)
Author:
Pat Tressel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrintRegionsAndIncidents

    v5 v6  
    5555   * The user's personal gis_config.
    5656   * The generic gis_config.
     57 * Filter entities that have locations by region.
     58  * Filter drop-down menus and other selectors.
     59  * Filter search results.
     60  * Filter lists.
     61  * Perhaps provide an option to view all entities?
     62    (This isn't necessary as one can deselect the region but might be convenient
     63    if one wants to find nearby entities.)
    5764
    5865The "region location" associates specific locations to the region.
     
    9097 * Information (e.g. work logs, instructions)
    9198
    92 Fran considered creating an org for each incident, as it has fields and components that would be appropriate, but says that may not be sufficient.
     99==== Use an org ====
     100Fran considered creating an org for each incident, as it has fields and components that would be appropriate, but says that may not be sufficient. Probably need at least a region in addition.
    93101
    94 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.  (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.)
     102==== Use relationship tables ====
     103Many 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.
     104
     105(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.)