# IT:AD:CRUS #

<callout type="Navigation" class="small">

* [[../|(UP)]]
{{indexmenu>.#2|nsort tsort}}
* See also:
    * https://en.wikipedia.org/wiki/Slowly_changing_dimension
    * http://stackoverflow.com/questions/24122569/version-history-of-database-entries-in-entity-framework
    * http://stackoverflow.com/a/1285942
    * As to CRUD syncing...keep an eye on this: https://github.com/Dancode-188/synckit 


</callout>


## Notes ##

* Regarding EF: 
    * is most easily implemented as a Type 4 process...with modifications.
    * Although correct, a Type 4 appraoch is not usable without additional work:
        * Any FK value will be pointing at a Reference table, not the ReferenceHistory table.
        * Yes, there is a Date range in the ReferenceHistory...but it requires heavyness when querying, to isolate the Reference record's activity window within which in the principle Entity's last modified date sits....
        * Options are to add to the Entity record a second FK column (FK2) column, that points to the RefHistory table. 
            * But it has to be nullable, and filled out of process.
            * Which has a risk of causing errors.
            * Integrity between Record and ReferenceRecord has to be broken (ReferenceRecord can be deleted) unless the Reference data record is only Soft deleted.


Therefore, consider the following requirements:

* All mutable entity and reference data tables need to be shadowed with their respective History table.
* A second FK column has to be added to all History tables, pointing to History Reference tables.  
    * The secondary FK MAY be nullable if intended to be processed out of band.
* Reference Data must be Soft Deleted (in order to not cause Referential failure from History table).