無唯一性欄位情況下，雙表關聯更新資料方案
阿新 • • 發佈：2019-01-06
需求是：
公司早先在另一個數據源D1整合了一套資料到專案中，如下文player資料，現又在新資料D2採集了一套新資料，想用D2的資料值更新公司現專案，要保留現專案的表id。
專案中的資料id用的是資料來源D1的，針對player表，如下圖，D1、D2該表均無唯一性標註欄位，只能通過姓名勉強匹配。
D1、D2中均有2條梅西的資料，實際上需將D2中id為3的資料更新到D1中id為1的梅西資料。
對於D1中有，D2中無的資料（如卡卡），不更新其值。
1.
1.1player_source的值為
1.2player_dest與未關聯轉換表的更新語句
2.
因此，我們需要先整理出兩個資料來源間的id對應關係表，如下圖表明，目的表的id為1的梅西，應該用源頭表id為3的梅西進行更新
新的SQL如下：
從圖中我們看出，dest表的梅西資料被成功更新，但是，其它資料被更新成空值了。還原下資料，重新修改SQL
3.從下圖我們看到dest表的資料有按需更新。
4.但是，我覺得這樣的SQL效率並不高。而且我本次的方案，必須基於先整理出轉換表為前提，這個轉換表資料，我可以通過SQL語句暫時造一部分出來，因資料冗餘及髒亂資料造成的轉換缺失，可通過人工干預生成，隨著資料來源的變動，這個轉換表必然要隨著修改，這是一個不小的工作量。懇請技術、方案指教。
SQL語句如下：
UPDATE player_dest dest SET dest.c1 = ( SELECT source.c1 FROM player_source source WHERE dest. NAME = source. NAME AND EXISTS ( SELECT 1 FROM player_tran tran WHERE tran.source_id = source.id AND dest.id = tran.dest_id AND tran.dataprovider = 'juhe' ))
公司早先在另一個數據源D1整合了一套資料到專案中，如下文player資料，現又在新資料D2採集了一套新資料，想用D2的資料值更新公司現專案，要保留現專案的表id。
專案中的資料id用的是資料來源D1的，針對player表，如下圖，D1、D2該表均無唯一性標註欄位，只能通過姓名勉強匹配。
D1、D2中均有2條梅西的資料，實際上需將D2中id為3的資料更新到D1中id為1的梅西資料。
對於D1中有，D2中無的資料（如卡卡），不更新其值。
1.
1.1player_source的值為
1.2player_dest與未關聯轉換表的更新語句
2.
因此，我們需要先整理出兩個資料來源間的id對應關係表，如下圖表明，目的表的id為1的梅西，應該用源頭表id為3的梅西進行更新
新的SQL如下：
從圖中我們看出，dest表的梅西資料被成功更新，但是，其它資料被更新成空值了。還原下資料，重新修改SQL
3.從下圖我們看到dest表的資料有按需更新。
4.但是，我覺得這樣的SQL效率並不高。而且我本次的方案，必須基於先整理出轉換表為前提，這個轉換表資料，我可以通過SQL語句暫時造一部分出來，因資料冗餘及髒亂資料造成的轉換缺失，可通過人工干預生成，隨著資料來源的變動，這個轉換表必然要隨著修改，這是一個不小的工作量。懇請技術、方案指教。
SQL語句如下：
UPDATE player_dest dest SET dest.c1 = ( SELECT source.c1 FROM player_source source WHERE dest. NAME = source. NAME AND EXISTS ( SELECT 1 FROM player_tran tran WHERE tran.source_id = source.id AND dest.id = tran.dest_id AND tran.dataprovider = 'juhe' ))
WHERE EXISTS ( SELECT 1 FROM PLAYER_TRAN TRAN WHERE TRAN.DEST_ID = dest.ID );
5.最麻煩的是，新資料來源D2中有，而公司資料來源D1中無的那些新增資料，其id要用公司資料來源D1中的最大id+1，獲取這個最大id，這樣的SQL語句也顯得很麻煩！再試想，萬一新資料來源D2不靠譜，那個新增的資料假設為“穆里尼奧”，這個月的id是100，下個月變為1000，這樣可就麻煩了。
6.我曾經整理過這樣的資料，想起來都覺得當時每天壓力好大。後來是直接放棄採用資料來源。該模組的資料交由另一家乙方公司推倒重做。當時在一家金融甲方現場做專案開發，前期遺留的髒亂太多，人員表中一人多號的現象十分嚴重，之前施工的同事遺留下一大堆坑。如果基礎底層模組都沒有打好，就拼命催著加後面的工程，很容易就是一個豆腐渣工程，而且有不少並沒有太多責任心的同事（或者說對專案前景的潛在風險沒有太多預見性的同事），現在有太多這樣的軟體豆腐渣工程了。其它的我就不多說了。