我正在構建一個基於多個屬性搜索人的工具。這些屬性的值分散在多個系統中。跨不同數據源搜索的策略
作爲示例，dateOfBirth作爲系統ABC的一部分存儲在SQL Server數據庫中。該人員的銷售地區分配存儲在一些可怕的遺留數據庫中。其他屬性存儲在只能通過XML Web服務訪問的系統中。
更糟的是，遺留數據庫和Web服務可能非常慢。
對於在所有這些系統中執行搜索，我應該考慮哪些策略和提示？
注意：儘管我發佈了一個答案，但我並不確定它是一個很好的答案。除非沒有人提供更好的見解，否則我不打算接受我自己的答案。
您可以考慮使用索引機制來檢索並本地索引所有系統中的數據，然後對索引執行搜索。搜索會更快，更可靠。
當然，這只是將問題從系統的一部分轉移到另一部分 - 現在索引機制必須處理故障和異構系統，但這可能是一個更容易解決的問題。
另一個因素是數據更改的頻率。如果您必須實時查詢數據，並且數據很快就會過時，那麼索引可能不實用。
如果您可以避開限制性搜索，請首先根據對應於最快數據源的搜索條件返回一個列表。然後將這些記錄與其他系統合併，並刪除與搜索條件不匹配的記錄。
如果你必須實現OR邏輯，這種方法是行不通的。
雖然不是一個真正的答案，但這至少可以幫助您達到可行的解決方案。我們在以前的僱主也有類似的情況 - 大量數據來源，訪問這些數據來源的不同方式，不同的訪問權限，軍事/政府/民事來源等。我們使用圍繞企業服務總線概念構建的Mule，將這些數據源連接到我們的應用程序。我的細節有點粗略，因爲我不是實際的實現者，只是一個集成者，但我們所做的是在Mule中定義一個頻道。然後你寫一個簡單的集成片段，在通道和數據源之間，以及應用程序和通道之間。整合部分完成了實際查詢和格式化結果的工作，因此我們有一個用於訪問數據庫的通用SQL集成部分，對於Web服務等，我們有一些基類實現了通用功能，所以實際整合式的定製化工作比聽起來要少很多。應用程序然後可以查詢通道，該通道將處理訪問各種數據源，將它們轉換爲XML的標準化位，並將結果返回給應用程序。
這對我們的情況有很多好處。我們可以將現有查詢的新數據源簡單地連接到頻道 - 應用程序不必知道或關心那裏的數據源，因爲它只查看來自頻道的數據。由於可以從通道推送或拉取數據，因此，例如，在更新應用程序時，我們可以讓數據源更新應用程序。
需要一段時間才能完成配置和工作，但一旦我們完成了設計，我們就會很成功。在我們的演示設置中，我們結束了4或5個應用程序，既可以作爲數據的生產者也可以作爲消費者，並且可能連接到10個數據源。
你有沒有想過將數據移動到一個單獨的結構？在要搜索
例如，Lucene的存儲數據的模式少倒索引。你可以有一個單獨的程序，它可以從你所有的不同資源中檢索數據，並將它們放入Lucene索引中。您的搜索可能會針對此索引起作用，並且搜索結果可能包含唯一標識符及其來自的系統。
http://lucene.apache.org/java/docs/ （還有在其他語言的實現）
你已經採取了看看YQL？這可能不是完美的解決方案，但我可能會給你起點。
嗯，首先我會並行查詢到不同的系統。這樣我們可以最小化查詢時間。
您也可能要考慮一下緩存和聚合搜索，以加快速度爲後續查詢屬性。
你必須創建一個彙集了所有的不同的系統，這樣就可以查詢提供一個單一的界面聚合服務或中間件的選擇。如果你這樣做，這是我會做前面提到的緩存和parallize優化。
然而，所有它，你需要權衡開發時間/部署時間/長期的努力的好處對舊舊的數據庫遷移到更快更現代的一個。你還沒有說過這些數據庫是如何與其他系統綁定的，所以在短期內它可能不是一個可行的選擇。
編輯：響應數據會過時。如果您的數據不需要數據始終與數據庫實時匹配，則可以考慮緩存。另外，如果某些數據不經常更改（例如出生日期），那麼您應該緩存它們。如果您使用緩存，那麼您可以使您的系統可配置爲包含或從緩存中排除哪些表/列，並且可以爲每個表/列提供個性化緩存超時且具有整體默認值。
使用的Pentaho /水壺複製所有數據字段，你可以搜索並顯示到本地MySQL數據庫
http://www.pentaho.com/products/data_integration/
創建一個批處理腳本，在夜間運行和更新您的本地副本。甚至可能每個小時。然後，將您的查詢寫入本地MySQL數據庫並顯示結果。
我喜歡這個想法最好，儘管可能會有一個更容易。 – djangofan 2009-07-29 00:49:45