學習雜記--- 貧血 充血 sql join

貌似是對於JAVA而言的  


貧血模型:是指領域對象裏只有get和set方法,或者包含少量的CRUD方法,所有的業務邏輯都不包含在內而是放在Business Logic層。
優點是系統的層次結構清楚,各層之間單向依賴,Client->(Business Facade)->Business Logic->Data Access(ADO.NET)。當然Business Logic是依賴Domain Object的。似乎現在流行的架構就是這樣,當然層次還可以細分。
該模型的缺點是不夠面向對象,領域對象只是作爲保存狀態或者傳遞狀態使用,所以就說只有數據沒有行爲的對象不是真正的對象。在Business Logic裏面處理所有的業務邏輯,在POEAA(企業應用架構模式)一書中被稱爲Transaction Script模式。

充血模型:層次結構和上面的差不多,不過大多業務邏輯和持久化放在Domain Object裏面,Business Logic只是簡單封裝部分業務邏輯以及控制事務、權限等,這樣層次結構就變成Client->(Business Facade)->Business Logic->Domain Object->Data Access。
優點是面向對象,Business Logic符合單一職責,不像在貧血模型裏面那樣包含所有的業務邏輯太過沉重。
缺點是如何劃分業務邏輯,什麼樣的邏輯應該放在Domain Object中,什麼樣的業務邏輯應該放在Business Logic中,這是很含糊的。即使劃分好了業務邏輯,由於分散在Business Logic和Domain Object層中,不能更好的分模塊開發。熟悉業務邏輯的開發人員需要滲透到Domain Logic中去,而在Domian Logic又包含了持久化,對於開發者來說這十分混亂。  其次,因爲Business Logic要控制事務並且爲上層提供一個統一的服務調用入口點,它就必須把在Domain Logic裏實現的業務邏輯全部重新包裝一遍,完全屬於重複勞動。


如果技術能夠支持充血模型,那當然是最完美的解決方案。不過現在的.NET框架並沒有ORM工具(不算上開源的NHibernate,Castle之類),沒有ORM就沒有透明的持久化支持,在Domain Object層會對Data Access層構成依賴,如果脫離了Data Access層,Domain Object的業務邏輯就無法進行單元測試,這也是很致命的。如果有像Spring的動態注入和Hibernate的透明持久化支持,那麼充血模型還是能夠實現的。 



聯接可分爲以下幾類: 

內聯接(典型的聯接運算,使用像 = 或 <> 之類的比較運算符)。包括相等聯接和自然聯接。 
內聯接使用比較運算符根據每個表共有的列的值匹配兩個表中的行。例如,檢索 students 和 courses 表中學生標識號相同的所有行。

外聯接。外聯接可以是左向外聯接、右向外聯接或完整外部聯接。 
在 FROM 子句中指定外聯接時,可以由下列幾組關鍵字中的一組指定:

LEFT JOIN 或 LEFT OUTER JOIN。 
左向外聯接的結果集包括 LEFT OUTER 子句中指定的左表的所有行,而不僅僅是聯接列所匹配的行。如果左表的某行在右表中沒有匹配行,則在相關聯的結果集行中右表的所有選擇列表列均爲空值。

RIGHT JOIN 或 RIGHT OUTER JOIN。 
右向外聯接是左向外聯接的反向聯接。將返回右表的所有行。如果右表的某行在左表中沒有匹配行,則將爲左表返回空值。

FULL JOIN 或 FULL OUTER JOIN。 
完整外部聯接返回左表和右表中的所有行。當某行在另一個表中沒有匹配行時,則另一個表的選擇列表列包含空值。如果表之間有匹配行,則整個結果集行包含基表的數據值。

交叉聯接。 
交叉聯接返回左表中的所有行,左表中的每一行與右表中的所有行組合。交叉聯接也稱作笛卡爾積。

例如,下面的內聯接檢索與某個出版商居住在相同州和城市的作者:

USE pubs
SELECT a.au_fname, a.au_lname, p.pub_name
FROM authors AS a INNER JOIN publishers AS p
   ON a.city = p.city
   AND a.state = p.state
ORDER BY a.au_lname ASC, a.au_fname ASC

FROM 子句中的表或視圖可通過內聯接或完整外部聯接按任意順序指定;但是,用左或右向外聯接指定表或視圖時,表或視圖的順序很重要。有關使用左或右向外聯接排列表的更多信息,請參見使用外聯接。 




例子:
a表  id name  b表  id job parent_id
      1 張3         1  23  1
      2 李四        2  34  2
      3 王武        3  34  4

a.id同parent_id 存在關係

內連接
select a.*,b.* from a inner join b  on a.id=b.parent_id

結果是 
1 張3         1  23  1
2 李四        2  34  2

左連接

select a.*,b.* from a left join b  on a.id=b.parent_id

結果是 
1 張3         1  23  1
2 李四        2  34  2
3 王武        null
右連接
select a.*,b.* from a right join b  on a.id=b.parent_id

結果是 
1 張3         1  23  1
2 李四        2  34  2
null        3  34  4

完全連接

select a.*,b.* from a full join b  on a.id=b.parent_id


結果是 
1 張3         1  23  1
2 李四        2  34  2
null        3  34  4
3 王武        null



USE pubs
SELECT a.au_fname, a.au_lname, p.pub_name
FROM authors a LEFT OUTER JOIN publishers p
ON a.city = p.city
ORDER BY p.pub_name ASC, a.au_lname ASC, a.au_fname ASC

下面是結果集:

au_fname au_lname pub_name 
-------------------- ------------------------------ ----------------- 
Reginald Blotchet-Halls NULL
Michel DeFrance NULL
Innes del Castillo NULL
Ann Dull NULL
Marjorie Green NULL
Morningstar Greene NULL
Burt Gringlesby NULL
Sheryl Hunter NULL
Livia Karsen NULL
Charlene Locksley NULL
Stearns MacFeather NULL
Heather McBadden NULL
Michael O'Leary NULL
Sylvia Panteley NULL
Albert Ringer NULL
Anne Ringer NULL
Meander Smith NULL
Dean Straight NULL
Dirk Stringer NULL
Johnson White NULL
Akiko Yokomoto NULL
Abraham Bennet Algodata Infosystems
Cheryl Carson Algodata Infosystems



發佈了68 篇原創文章 · 獲贊 11 · 訪問量 15萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章