# Same-As Link Advice **URL:** \ **Category:** Data Vault 2.0\ **Created:** [February 20, 2023, 9:09am UTC](https://forum.data-community.org/t/same-as-link-advice/622 "2023-02-20T09:09:06Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![justin](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.data-community.org/justin/32/163_2.png) [@justin](https://forum.data-community.org/u/justin)\ **Post date:** [February 20, 2023, 9:09am UTC](https://forum.data-community.org/t/same-as-link-advice/622/1 "2023-02-20T09:09:06Z")
I have two raw source files that contain the relationship between a customer\_id and its various IDs from other systems. The first file has our old, internal customer\_id along with a third party vendor ID we’ll call ven1\_customer\_id. Whenever I loaded that file, I loaded both into HUB\_CUSTOMER with the BKCC as “VEN1” for the the third party IDs. I then setup a SAL\_CUSTOMER\_VEN1 table with their respective HKEYs to link the two together. That was all fairly straightforward. The issue or question I have is with the second file which has, again, our old customer\_id and our _new_, internal customer\_id (new\_customer\_id) as well as another third party vendor we’ll call ven2\_customer\_id. This file only has a sent\_timestamp and a load\_timestamp outside of those three ID fields. My plan is to load the three IDs into HUB\_CUSTOMER but I don’t know what the best method is for loading SAL(s). Should I also add a BKCC value for the new customer\_id we’re using? I was going to add “VEN2” for the third ID field. Would I create a SAL\_CUSTOMER\_NEW and a SAL\_CUSTOMER\_VEN2? Should it all be stacked into one SAL\_CUSTOMER\_NEW\_VEN2 table? ---
**Author:** ![AHenning](https://avatars.discourse-cdn.com/v4/letter/a/96bed5/32.png) [@AHenning](https://forum.data-community.org/u/AHenning)\ **Post date:** [February 20, 2023, 5:22pm UTC](https://forum.data-community.org/t/same-as-link-advice/622/2 "2023-02-20T17:22:55Z")
Hello! Very short answars. 1. Yes 2. No 3. Yes Good luck! ---
**Author:** ![patrickcuba](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.data-community.org/patrickcuba/32/19_2.png) [@patrickcuba](https://forum.data-community.org/u/patrickcuba)\ **Post date:** [February 21, 2023, 12:06am UTC](https://forum.data-community.org/t/same-as-link-advice/622/3 "2023-02-21T00:06:09Z")
Hey Justin, For the first instance I would **not** recommend a SAL here, reasons: - you have no guarantee what the vendor’s business key integrity is, even if it a business key at all and - you have no control over how they manage those keys. Your customer id should be loaded into the hub but the vendor’s keys should be nothing more than an attribute on a satellite table. - In the context of a bkcc imagine you would have one for every vendor! How do you ensure those are not duplicated within the vendor itself! To you it should be treated as a Junk Key! - Imagine further the types of queries you need to write to resolve this too! Join, hub to SAL, SAL to hub whereas you could simply lookup the customer id and refer to satellite table! For the follow-on question, it appears the load timestamp is not your own - remember the load time stamp is when you load data into your data vault. ---
**Author:** ![justin](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.data-community.org/justin/32/163_2.png) [@justin](https://forum.data-community.org/u/justin)\ **Post date:** [February 21, 2023, 2:04pm UTC](https://forum.data-community.org/t/same-as-link-advice/622/4 "2023-02-21T14:04:24Z")
Thank you, @patrickcuba. I bought and read your book, by the way. One of the better (and only) resources out there for Data Vault that isn’t really old (in technology time). Anyway, I realize I need to add some more information to my original question. The first vendor’s ID will most likely work better as you suggested, simply as an attribute in a satellite of HUB\_CUSTOMER. The second one, however, has many tables that house all of the purchase transactions and other business info about the customer that I will have to link together for reporting. You are correct in that I have no control over their data and whether it will have dupes or not but I don’t have much of a choice, I’m afraid. So, next steps: 1. I will drop the SAL\_CUSTOMER\_VEN1 table and just have that vendor ID number stored in a SAT. 2. I will load the second, more important vendor ID into the HUB\_CUSTOMER table and setup a SAL with the three values (our old internal, our new internal, and the vendor’s ID) that are in the one source file. Do you concur or have a better suggestion? ---
**Author:** ![patrickcuba](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.data-community.org/patrickcuba/32/19_2.png) [@patrickcuba](https://forum.data-community.org/u/patrickcuba)\ **Post date:** [February 21, 2023, 9:45pm UTC](https://forum.data-community.org/t/same-as-link-advice/622/5 "2023-02-21T21:45:11Z")
My advice there is two-fold 🙂 1. Make your Data Executive accountable for decisions that might put your butt on the line, i.e. you might be creating a legacy platform (a ball of technical debt) 2. You might need a reliable system to process that secondary source data and allocate reliable business keys and some hard business rules applied that are signed off by the business. This secondary system becomes your source to DV SAL with a vendor id might be really dangerous, for the reasons I mentioned above. We worked in a debt collection company with managed debt (debt a vendor/retailer could not collect and was handed over to us). They had an account\_number/account\_id/\_\_accno (you get the idea) but we processed that into our source and allocated a debt\_id to it. To the retailer they still retain their bkeys but to us and the rest of the business we always referred to this debt via the debt\_id, debt\_id is our reliable business key. ---
**Author:** ![justin](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.data-community.org/justin/32/163_2.png) [@justin](https://forum.data-community.org/u/justin)\ **Post date:** [February 21, 2023, 10:10pm UTC](https://forum.data-community.org/t/same-as-link-advice/622/6 "2023-02-21T22:10:22Z")
Allocated a debt\_id meaning something you generated within the database? A sequence generated key type scenario? ---
**Author:** ![patrickcuba](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.data-community.org/patrickcuba/32/19_2.png) [@patrickcuba](https://forum.data-community.org/u/patrickcuba)\ **Post date:** [February 21, 2023, 10:16pm UTC](https://forum.data-community.org/t/same-as-link-advice/622/7 "2023-02-21T22:16:02Z")
The business treated it as a business key, I don’t remember if it was a sequence key explicitly or if there were some smarts in it (I worked for them 19 years ago!). The best part of this was that we did not have to manage this at all – the data developers and administrators of that system did and hence managed the business rules to ensure those debt\_ids were strong, valid and unique. It also meant we did not introduce this potentially devastating technical debt (if we relied on vendor ids) into DV. ---
**Author:** ![RhysHanscombe](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.data-community.org/rhyshanscombe/32/394_2.png) [@RhysHanscombe](https://forum.data-community.org/u/RhysHanscombe)\ **Post date:** [December 1, 2025, 2:47pm UTC](https://forum.data-community.org/t/same-as-link-advice/622/8 "2025-12-01T14:47:42Z")