對象關係映射問題：需要的建議

我一直在想出一個好的設計模式，用於將包含在關係數據庫中的數據映射到我創建的業務對象，但我一直在打牆。對象關係映射問題：需要的建議

考慮以下表：

TYPE: typeid, description 
USER: userid, username, usertypeid->TYPE.typeid, imageid->IMAGE.imageid 
IMAGE: imageid, location, imagetypeid->TYPE.typeid

我想收集所有關於特定用戶的信息。爲此創建查詢並不困難。

SELECT u.*, ut.*, i.*, it.* FROM user u 
INNER JOIN type ut ON ut.typeid = u.usertypeid 
INNER JOIN image i ON i.imageid = u.imageid 
INNER JOIN type it ON it.typeid = i.imagetypeid 
WHERE u.userid = @userid

的問題是，字段名稱衝突，然後我不得不別名每一個領域，它們很快失控。

有沒有人有這樣的事情體面的設計模式？

我想過從單個存儲過程中檢索多個結果，然後使用數據集來遍歷每個結果，但我擔心一些性能問題可能會在以後咬我。例如，而不是上述查詢類似：

SELECT u.*, t.* FROM user u 
INNER JOIN type t ON t.typeid = u.usertypeid 
WHERE u.userid = @userid; 
SELECT i.*, t.* FROM image i 
INNER JOIN type t ON t.typeid = i.imagetypeid 
INNER JOIN user u ON u.imageid = i.imageid 
WHERE u.userid = @userid;

這看起來像一個體面的解決方案嗎？任何人都可以預見這種方法的任何問題嗎？

來源

2009-01-08 Spencer Ruport

後面的解決方案似乎不好，簡單地說。你不覺得別名是一個更好的方式去。順便說一句，你真的使用任何ORM框架？ – 2009-01-08 07:28:32

Wot沒有ORM框架在使用？這是什麼語言？ – 2009-01-08 07:30:03

切勿在生產代碼中使用SQL *通配符。總是拼出你想要檢索的所有列。

然後別名其中一些似乎不是如此大量的額外工作。

回覆您的留言，詢問有關背景知識和推理：

有時候，你並不真的需要從所有表每列，並獲取他們可能是不必要的昂貴（尤其是大串和斑點）。除「以下例外情況外，沒有SQL語法」。
您不能別名使用通配符獲取的列。一旦您需要爲任何列別名，您需要展開通配符以明確列出所有列。
如果表結構發生變化，例如，列被重命名，重新排序，刪除或添加，然後通配符按照表中定義的位置全部獲取它們。這可能看起來很方便，但是當應用程序依賴於給定名稱或給定位置的結果集中的列時，這並不適用。如果應用程序以錯誤的順序顯示列（如果按位置引用列），或者將它們顯示爲空白（如果按名稱引用列），則可能會出現一些神祕錯誤。

但是，如果SQL查詢顯式命名列，則可以使用「Fail Early」原則。這有助於調試，因爲它直接導致您需要編輯的SQL查詢來說明模式更改。

來源

2009-01-08 07:15:22

對象關係映射問題：需要的建議

回答

相關問題