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