" However, doesn't Eloqua use the email address as the unique key for a contact? They'd have to change that, wouldn't they, to solve this issue? "
Not at all. Eloqua uses email address as A unique key, not THE unique key. In database terms, the email address is a "candidate key", so no they would not have to change the way they use the email address or relate child data. Behind the scenes, each contact has a ContactId, which is the "primary key" (the one candidate key to rule them all!) for the Contact table. You can see the value of this field in the Field Details view of a Contact. Actually, what is displayed is something like this: CHSLD000000000126, but the actual ContactId is simply the numeric portion (126). All child data (activity and campaigns the contact record is in) have a "relationship" to the Contact. A relationship is defined by a child table having a field, or set of fields, (called the "foreign key") that stores value(s) that reference a candidate key in the parent table. So with ContactId and Email Address as candidate keys in the Contact table, Eloqua can relate child records to a contact record via the ContactId or Email Address values. So, as an example, the Activity table would have a ContactId field and its value would be the ContactId of the Contact the activity data is for. In database design, it is often preferred to relate tables via a candidate key that does not change -- ever! -- like the ContactId. However, if the email address (which is editable) is used to relate tables, the database engine has to enforce referential integrity by "cascading updates" to the child tables. What that means is that if the Email Address value changes on the Contact record, the database engine would "cascade" that update to the foreign key fields of all the child tables that reference Email Address in order to maintain the relationship between the Contact and their child data ... like campaign activity and general activity ... and a Contacts' subscription group preferences should be relationship that is maintained!!, but it is currently not.
By not maintaining the relationship (aka: cascading updates of email address), the act of changing an email address on a contact, severs the subscription preferences from the Contact record, thus creating "orphans" in the subscription preferences table. Those orphans will be there "forever" until someone becomes their parent again. ANY contact can assume the "parent" role to those orphans by using the value of an orphaned records' email address. That is how we currently can get a situation like this:
Contact1: emailAddress1
+--- Subscription 1
+--- Subscription 2
+--- Subscription 3
Contact2: emailAddress2
+--- Subscription 4
+--- Subscription 5
+--- Subscription 6
--- then swap email addresses through an intermediary ---
Contact1: emailAddress2
+--- Subscription 4
+--- Subscription 5
+--- Subscription 6
Contact2: emailAddress1
+--- Subscription 1
+--- Subscription 2
+--- Subscription 3
It is clear through documentation, presentation of data through the user interface, API calls, CAN-SPAM laws Eloqua customers must adhere to, and general expectation of database behavior, that subscription preferences belong to a Contact and a change in email address should not sever those preferences from that contact and make them available to someone else. Changing a contacts' email address does not effect the related activity log or any other child data that I know of. In addition, a change of email address does not effect the contacts' Global Subscription election. Therefore, a change in contacts email address should not effect a contacts' individual subscription elections.
This is a bug and our organization has been effected greatly by this bug. ALL Eloqua customers are effected by this bug, and it is my estimation that the majority of Eloqua customers do not know this is happening, but would be upset if they knew about it. I have recommended to my company to drop Eloqua if they don't fix this issue, we are an enterprise level customer of Eloqua's and they may not notice the loss of one client, but our business cannot function effectively with Eloqua if they maintain the current condition and call it a feature instead of a flaw.
Setting the database engine to "cascade updates" of foreign keys is a very simple thing to do, come on Eloqua! ... do the right thing!!