我們有一個包含約100K業務對象的數據庫。每個對象都有大約40個屬性存儲在15個表中。我必須得到這些對象，對它們執行一些變換，然後將它們寫入不同的數據庫（具有相同的模式）。 這是ADO.Net 3.5，SQL Server 2005.需要幫助設計大型數據庫更新過程
我們有一個庫方法來編寫一個單一的財產。它計算出屬性進入的15個表中的哪一個，創建並打開一個連接，確定該屬性是否已經存在，並相應地進行插入或更新，並關閉連接。
我在程序中的第一遍是從源數據庫中讀取一個對象，執行轉換，並在其40個屬性中的每個屬性上調用庫例程以將對象寫入目標數據庫。重複10萬次。顯然這是非常不合情理的。
處理這類問題有哪些好設計？
感謝
這正是諸如此類的事情，是SQL Server集成服務（SSIS）是良好的。它在Books Online中有記錄，與SQL Server相同。
不幸的是，我會說你需要忘記你的客戶端庫，並在SQL中完成所有的工作。
你需要多少次這樣做？如果只有一次，而且它可以無人值守運行，我看不出有什麼理由不應該重用現有的客戶端代碼。自動化人的工作是計算機的用途。如果效率低下，我知道這很糟糕，但是如果你打算花一週時間建立一個SSIS包，那也是無效的。另外，您的客戶端解決方案可能包含業務邏輯或驗證代碼，您必須記住將它們傳遞給SQL。
您可能想要研究Create_Assembly，將您的客戶端代碼移到網絡上以駐留在SQL框中。這將避免網絡延遲，但可能會破壞SQL Server的穩定性。
我需要每週做一次，目前大概需要13個小時。它可以無人看管，我通常在回家之前就開始這個過程。但是讓我感到困擾的是，有這樣一個低效率的過程，我真的想讓它更加優雅。因此，我要求更有效的設計。 – Sisiutl 2009-06-19 17:46:49
如果我是你，我會優化你現有的客戶端代碼。我敢打賭，有很多優化的機會。例如，你是否爲每個對象屬性或每個對象執行一個數據庫命令？你是連接池還是打開/關閉每個通話的連接？按照我的計算，你只能得到〜每秒兩個物體。通過仔細的優化，一些索引調優等，你可能會把它們縮短到幾個小時，這是合理的，不需要重寫。 – 2009-06-19 18:22:03
壞消息：你有很多選擇
使用簡單文件轉換：提取所有數據到flatfiles，用grep，awk中，sed的，C，Perl的成所需要的插入/更新語句操縱它們並執行那些反對目標數據庫
PRO：快速; CON：非常醜陋......保鏢的噩夢，如果你需要更長一個星期的時間，那麼不要這樣做。和幾十個處決
使用純sql：我不太瞭解sql服務器，但我認爲它已經遠離從另一個訪問一個數據庫，所以其中一個最好的辦法是做到這一點把它作爲一個'insert/update/merge語句的集合，用select語句提供。
PRO：快速，只有一種技術; CON：需要數據庫之間的直接連接根據轉換的類型，您可能會很快達到SQL的限制或可用的SQL知識。
使用t-sql或數據庫提供的任何迭代語言，其他所有內容都類似於純sql aproach。
PRO：相當快，因爲你不離開數據庫CON：我不知道t-sql，但如果它是像PL/SQL那樣的東西，它不是執行復雜轉換的最好語言。
使用高級語言（Java，C＃，VB ...）：您會將數據加載到適當的業務對象中，操作這些數據並將它們存儲在數據庫中。儘管聽起來有更好的ORM可用，但它與您目前正在做的似乎很相似。 nhibernate
使用ETL工具：有用於提取，轉換和加載數據的特殊工具。他們經常支持各種數據庫。並有許多策略可用於決定是否有更新或插入。
PRO：對不起，您必須向其他人諮詢，我到目前爲止只有不好的經驗。 CON：高度專業化的工具，您需要掌握。我個人的經驗：在實現和執行轉換後手寫SQL更慢。這是可維護性的噩夢，因爲所有東西都隱藏在專有存儲庫中，所以對於IDE，版本控制，CI，測試，如果存在任何工具提供者，您都會被卡住。
PRO：即使是複雜的操作也可以用乾淨的可維護方式實現，您可以使用IDE，測試框架，CI系統等所有花哨的工具在開發轉換時爲您提供支持。
CON：它增加了很多開銷（從數據庫中檢索數據，實例化對象，並將對象編組回到目標數據庫中）。如果它是一個正在進行的過程，我會這樣做
基於最後一個選項，您可以使用消息傳遞和Web服務進一步美化架構師，如果您擁有多個源數據庫或多個目標數據庫，則可能是相關的;或者你可以手動實現一個多線程變壓器，以獲得通過，但我想我離開你的問題的範圍。
我與約翰，SSIS是去任何重新的方式可以進行大量的數據導入。它應該比目前獲得的30個小時快得多。如果兩個數據庫位於同一臺服務器上或連接的服務器上，您也可以編寫純粹的t-sql代碼。如果你走t-sql路線，你可能需要做一個混合的基於集合和循環的代碼來運行批處理（一次說2000條記錄），而不是整個表鎖定一個大插入採取。
+1正好 - ETL（extract - transform - load）最好:-) – 2009-06-19 16:53:35