Changes between Version 5 and Version 6 of S3/S3Model/SuperEntities


Ignore:
Timestamp:
11/01/10 23:40:30 (14 years ago)
Author:
Dominic König
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • S3/S3Model/SuperEntities

    v5 v6  
    55== Introduction ==
    66
    7 Sometimes it is useful to share the same component among multiple resources. To realize this, S3XRC uses link tables - so-called ''Super-Entities''.
     7Sometimes it is useful to share the same component across multiple resources. To achieve this in a generic way, S3XRC uses link tables - so-called ''Super-Entities'':
    88
    99[[Image(superentity.png)]]
    1010
    11 Instead of having several foreign keys for different primary resources, the shared component contains only one foreign key for the link table.
     11Instead of having several foreign keys for different primary resources, the shared component contains only one foreign key to the link table, the so-called ''super-key''.
    1212
    1313The primary resource (=instance table) contains the same ''super-key'' field as the component, thus the forward join of resource-to-component can be established as a natural join, i.e. without accessing the link table.
     
    1515For the (seldom needed) backward join component-to-resource, the link table needs to be involved because it contains the table name of the primary resource in the field {{instance_type}}.
    1616
    17 Disadvantage of the link table method is that the link table needs to be updated whenever a primary resource record is created, updated or deleted. Thus, it is recommended to not use super-entities for resources where the extra load on write can give a serious performance problem (e.g. messages), or at least to keep the super-entity table lean and free of extra references.
     17Disadvantage of the link table method is that the link table needs to be updated whenever a primary resource record is created, updated or deleted - which generates some (minimal) extra load on write, however, it is recommended to not use super-entities for resources where the extra load on write can give a serious performance problem (e.g. messages), or at least to keep the super-entity table lean and free of extra references.
    1818
    1919  - ''code examples to follow...''