我最早使用的一個關系型DBMS就是 Microrim‘sRBaseRBase與其PC競爭對手dBase不同的是它是真正的關系型數據庫管理系統是在世紀年代初作為NASARIM(關系信息管理RelationalInformationManagement)系統的一個PC版本開發出來的而我最欣賞的功能之一是它允許用戶在導入過程中查看示例數據盡管像bcpDTS新的SQLServer集成服務這樣的工具以及各種移植工具和向導已經將數據導入過程自動化到SQLServer之中但這不意味著我們可以一勞永逸本月RonTalmage提供一些關於導入數據的非常好的常識性建議
SQLServerDBA(DatabaseAdministrator數據庫管理員)發現他們經常使用TSQL導入和處理數據為什麼呢？因為一些數據傳輸需要技術成熟的SQL所具備的強大功能最近我剛好完成了另一個數據導入的案例該案例觸動我匯編了一份供我使用的行為規范列表
確保將載入的原始數據暫存為varchar數據類型
源自所謂的舊式系統的原始數據通常以文本格式傳送因此我首先總是將原始數據載入一個單獨的暫存數據庫我從不嘗試將數據直接載入一個成品數據庫
我做的事情是將所有原始文本數據載入相應的原始表表中的列為varchar數據類型(DTS將自動完成該過程這樣很好但是DTS還會將列命名為COL因此您不用事先提供列名)varchar的主要優點是它能夠接收任何數據甚至是“壞”數據如果您嘗試從一個沒有對用戶輸入的數據進行嚴格檢查的舊式系統加載數據那麼被忽略的數據或寫入異常文件的數據可能比加載的數據還多如果您不想冒這樣的風險除非接收每一個可能的值將字符載入varchar數據類型的列則可以做到這一點
在暫存表/列名時不要使用非字母數字字符
您可能無法控制在包含原始數據的表中如何對列進行初始命名但是我會嘗試修改可能包含空格或其他非常規字符的舊式列名當列名或表名包含非字母數字的字符時我們必須使用方括號或雙引號對其進行分隔這種代碼不但編寫起來比較困難而且可讀性較差
不要在列名中使用關鍵字
源自舊式系統的數據通常包含能夠破壞SQL查詢的描述性列名例如房地產數據可能會包含一個名為KEY的列它用來反映放置在待售房屋上的鑰匙箱然而KEY也是TSQL中的一個關鍵字(！)如果使用這樣的列名查詢操作在直接引用該列名時將失敗因此最終您必須用方括號或雙引號分隔含有關鍵字的列名
確保使用正確的數據類型創建一個暫存表
下一步是創建一個或多個額外的暫存表這些表有“正確的”數據類型我喜歡使暫存表和目標 OLTP(OnlineTransactionProcessing聯機事務處理)數據庫中的目的表具有相同的列名不管怎樣重要的是原始數據中每列的數據類型在載入暫存時都將執行檢查並予以改正在SQLServer表中找到壞數據比在加載失敗的外部文件中找到壞數據容易得多
確保將新列添加到暫存表中
當暫存數據沒有相應的列時您可以添加這些列然後拆分或合並載入的數據例如即使目的表分解出街道名和門牌號地址仍然可能作為一個簡單的字符串載入暫存表那麼您可以在暫存表中添加街道名列和門牌號列將舊式地址分解為兩個列這樣做的優點是原始數據與新拆分的數據並存因此您能夠通過比較列來測試腳本
確保使用本地副本來測試填充的產品數據
當您准備好要插入暫存表的數據時可以首先通過將其插入成品表的本地副本來測試這些數據有時您只需清空表有時您必須填充表
確保保留產品約束
在副表上總是保留產品約束這樣您就能夠測試暫存表數據滿足這些約束的程度這些約束包括NULL默認值檢查主鍵和外鍵約束首先保證副表列上的NULL或NOTNULL屬性與目標系統的相同然後再逐步檢查其他所有約束如果您的測試表明暫存數據插入過程滿足所有約束那麼您距離成功就只有一步之遙了
確保在一個產品數據副本上測試
雖然將導入數據插入空表將遇到很多潛在的問題但是不會遇到所有的問題在通過了所有之前的測試後確保您將在一個目標數據或成品系統的副本(或至少是一個合理的子集)上測試導入您能夠接收的最終錯誤類型將由數據配置決定而且這是此項測試能夠檢測到的那麼您就能夠在數據庫副本中檢查結果甚至可能將應用程序重定向到該副本以便進一步測試和驗證【專欄作家TomMoreau補充說“使用每日成品更新數據進行測試可以為數據移植做准備如果原來的系統沒有足夠的約束而新系統有那麼壞數據將進入原來的系統並破壞您的移植”Ed】
如果導入過程至此通過了所有測試那麼您可能已經准備好進行導入數據了或者至少可以將導入過程交給質量管理員(QAQualityAssurance)了
From:http://tw.wingwit.com/Article/program/SQLServer/201311/22261.html
