Aptify offers two implementations of Embedded Data Objects: Non-Shared and Shared.

Non-Shared Embedded Objects

A non-shared object is an embedded link that provides a one-to-one relationship between the parent record and the embedded record. For example, in Aptify, the Message Parts service has an embedded, non-shared link to the Scripts service, since a particular script corresponds to a single Message Parts record. See Creating Non-Shared Embedded Objects for information on how to create a non-shared embedded link.

Shared Embedded Objects

A shared embedded object corresponds to an embedded record that may be linked to multiple records. For example, consider the example of an application that includes a Companies entity and a Persons entity that are used to manage customers at the organizational and individual level. Companies and individuals frequently share address information. Using a normalized model such as the one described in  Understanding the Embedded Object Model, it is possible to link a company and its individuals directly to the same record in the Addresses table. This would reduce the number of records in the system and also speed up transactional performance when adding new persons to an existing company since a new record would not need to be inserted into the Addresses table. Furthermore, space requirements in the database would be reduced in this model and when an address is changed at the company level, it would automatically be reflected in all persons linked to the same physical Addresses record.

While this type of data modeling is desirable in some areas of a database, it can be undesirable in others. In some applications and in some table relationships it may be necessary for a record to have exclusive ownership of an embedded object. In that case, the concept of sharing would not be used at all.

For example, in the case where a company and multiple persons linked to it are sharing an address, if an individual within the company has a unique address, it is important that the unique address of that individual be respected and not overwritten when a company's address changes. The rest of the individuals linked to the company should get the new company address automatically, but an individual that previously had a different address than the company address should retain that unique address.

This type of functionality has existed in the Aptify CRM and Membership applications in several relationship areas including Companies/Persons and Organizations/Employees. However, in prior versions of the business applications, this flow-down actually was a physical flow-down of data from the Companies record to the Persons record and from the Organizations record to the Employees record. Whenever a companies address was changed, each person linked to the company was evaluated, and if the address at the person level was the same as the old company address, a flow-down occurred.

This type of business application functionality is common place and desirable at a logical level. In Aptify, embedded object sharing supports this scenario, but through a much more efficient process. Rather than physically flowing down data, records can be shared and therefore automatic "flow-downs" occur since Persons and Companies that are intended to share an address are linked to the same Addresses record.

If all shared embedded object scenarios desired to have complete auto-flow-down of data then the concept of sharing embedded objects would be a simple one to implement. All the user would need to do is link in the same embedded object primary key value into multiple "container" records. Whenever any such container record made a change to the embedded object, all other container records would automatically get the change. The problem, of course, is this is not always desired. In some cases, the desire is for the "flow" to occur only in one direction — from Company to Person, but not the other way.

Therefore, Aptify's shared embedded implementation also deals with these types of situations where an automatic record update is not desired, such as when a person has a different address than his or her company or when an order has an address specified as a Ship To destination.

Shared embedded objects eliminate the need for many custom flow-down scenarios in business application code and also can increase the efficiency of common transactions, such as changing an address of a company that might have many individuals linked to it. See Designing and Creating Shared Embedded Objects for more information on shared embedded links and their implementation.