Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <28749325.post@talk.nabble.com>
Date: Tue, 1 Jun 2010 18:51:31 -0700 (PDT)
From: "John J. Franey" <jjfraney@gmail.com>
To: users@camel.apache.org
Subject: surrogate key and integration pattern
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

I'm looking for a discussion regarding the temptation to use surrogate keys
in integration data.

I know that exposing a surrogate key to an external system will naturalize
the key, it would become a business data element.  I want to avoid that. 
However, we find we have a requirement to use a unique identifier to
correlate the entity among the systems that share the entity.  That
identifier would likely be called an 'id', just like the surrogate key.

Are you successful in keeping your surrogate key hidden, and how do you do
that?

I want to keep the surrogate key of a Customer, named 'id', hidden. 
Unfortunately, a business level identifier would also be called a 'customer
id'.  In order to avoid a confusion, there is temptation to expose the
Customer id field.  I don't have a good name for the business level
identifier.


Thanks,
John

-- 
View this message in context: http://old.nabble.com/surrogate-key-and-integration-pattern-tp28749325p28749325.html
Sent from the Camel - Users mailing list archive at Nabble.com.