**External Storage of Attributes**
----
The External Storage option for [relationalattributes](hs70) was introduced to resolve several shortcomings and issues in earlier versions of InstantObjects. These include the following:
the inability to fully query the database from a SQL-enabled (non-IO)interface;
the inability to define foreign keys to enforce referential integrity at the database level;
difficulty in repairing a \"corrupted\" blob due to the nature of its binary storage. This was somewhat alleviated with the introduction of the XML option for blobs but had the added problem of increased blob size and resulted in poorer performance;
the poor retrieve performance due to the missing implementation of load-on-demand feature for part, parts and references attributes.

The external storage option provides the ability to specify that a particular part, parts or references attribute should be mapped outside of its class table. For [containerattributes](hs70) this mapping is implemented through an additional linking table. In the case of part attributes, the intermediate object is not needed because the relationship between the owner and the part is 1:1.

The linking table has fields to hold information about both the relationships and the sequence of elements in the container attribute.
The mapping of the external reference(s) attribute is very similar to that for the external part(s) attribute. The only difference is one of ownership which results in the part(s) attribute\'s table record(s)being deleted when the its related class table record is deleted. This of course does not happen with reference(s) attributes.

**How to use external storage**
The external storage option can be applied in the Attribute Editor by setting *Storage Kind* to the value \"External\" when defining a new attribute.

![](AttributeEditorDefinitionExternal.gif)

The **Storage Kind** combo-box allows a selection between *Embedded*(the classic model) and *External* (the new model). For Part attributes that (in addition to defining the target class *stored* and not *embedded*) is enough. For Parts and References you also need an **External Storage Name** entry, that is the name the linking table will have. The default naming convention is to use \"\<class storagename\>\_\<attribute name\>\" for new attributes, but any other suitable naming scheme may be used. If **Auto** is checked the default naming scheme will be used to update the **External Storage Name** entry to the current values of its component names (eg. \<class storage name\> and\<attribute name\>).

IMPORTANT NOTES:***External Storage and Class Persistence*** - A class must have its Persistence property set to *stored* if it is referred to by attributes that use *external* storage. A class defined with *embedded* Persistence may only be used by *embedded* (the InstantObjects historical arrangement) part and parts attributes;***Performance Hint*** - Currently, the InstantObjects library does not create parent class indices for the linking tables in the database. A significant improvement in performance, therefore, can often be achieved by manually adding these indices (fields \'ParentClass\' and \'ParentId\', non-unique) to the linking tables for your external [container attributes](hs70). Remember that these manually added indices will be removed by each database build and probably after an evolve, so they will need to monitored and re-added as necessary. The need to add these indices manually will be eliminated after the introduction of Referential Integrity options to IO. This is expected to happen in the near future and will enhance both the integrity of data in and performance of the database for brokers that can implement Referential Integrity.