關係永續性建模
物件導向是偉大的技術。關聯式資料庫是偉大的技術。如果這兩種技術相互隔絕，那將是人類生活的一次災難，更是我們的巨大悲哀。幸運的是，這種假設沒有成為現實。上述兩種偉大的技術得到了人們的重視，同樣應該受到重視的還有如何將它們調和在一起。
並不是世界上所有的東西都能夠輕而易舉地結合起來。關聯式資料庫和物件導向就是這樣。可是造物弄人，偏偏是這樣背景不同特性迥異的兩個東西卻有著乙個無法抗拒的理由把它們聯絡到一塊。同時使用關聯式資料庫和物件導向技術可以使我們編寫出能夠管理大量資料的複雜的應用程式。正是基於此，才使我們有如此大的衝動，想要認真**一下關聯式資料庫與物件導向之間究竟有哪些異同。
首先讓我們來了解一下關係資料庫系統所具有地特點∶
資料以二維**形式表達；
表中資料之間的關係以儲存在表中的值來表達；
使用sql，可以動態地建立資料之間的關係；
具體的某些資料實體之間的關係在資料庫最初設計時，不一定要定義或可觀察。
在來看一下物件導向系統地特點∶
應用程式由一組物件組成，物件當然包括屬性和操作；
物件是由開發者定義的資料型別；
物件之間可能具有很複雜的關係，如繼承、關聯、聚合和組合；
類，準確地說是資料型別，之間的關係不容易修改，也不容易在系統建成之後動態建立；
持久物件應該可以儲存到外儲存器上。
基於他們各自的這些特點，關聯式資料庫和物件導向之間存在以下不同∶
型別系統不同；
語言不同；
範例不同；
基本資料實體不同。
不同的型別系統
關聯式資料庫型別系統比較簡單。關聯式資料庫資料型別用來定義資料庫表中的字段。儲存在字段裡的資料必須符合該列的型別。每一行每一列的資料型別必須是原子的。物件模型則比較複雜。每個物件都可以包含眾多屬性和操作。所以物件顯然不是原子性的。我們根本無法在表中儲存物件。物件的特性是封裝、繼承和多型性。而關聯式資料庫裡談這些都是廢話。
不同的語言
關聯式資料庫裡我們使用sql完成所有的事情。但是sql沒有處理物件的能力，不可能支援封裝、繼承、多型。sql最基本的目的就是訪問資料庫表裡面的資料，這是它唯一能做的。而物件導向的語言則可愛得多。支援封裝、繼承、多型。我們可以隨心所欲建立複雜的資料型別。但是當我們必須把大量持久物件寫在硬碟上並且時不時進行查詢時就會發現，這些語言在這方面的能力實在蹩腳。sql可以儲存並查詢大量資料，但沒有物件處理能力。物件導向語言能夠處理複雜的物件，但物件持久化方面的能力非常弱。
不同的範例
使用關係模型必須讓資料適應模型，而物件導向則需要盡力使模型適應真實世界。
不同的基本資料實體
物件模型到關係模型的對映，是類到關係表之間的對映。類對應著表，物件對應著記錄，屬性對應字段。困難在於，物件導向語言的基本資料實體是類，而關係模型的基本資料實體是字段。
以上的四點不同最終導致了我們在設計階段的困難。對於我們這些篤信物件導向的傢伙來說，災難往往發生在設計階段接近尾聲，編碼工作即將來臨之際。當我們費盡九牛二虎之力，在用況圖上畫出一堆又一堆達芬其的雞蛋，完成了充滿律動的順序圖，製作了嚴肅規整的類圖並且在上面布滿各式各樣的小箭頭之後，突然發現，我們真正需要的是乙個能夠方便儲存大量資料的關聯式資料庫，借助它才是把那些活躍的小物件們安頓到硬碟上的最好方式。但是我們如何才能得到這個急需的關聯式資料庫呢？難道我們就應該回到最初的需求文件，按照傳統的方式，從頭再來一遍嗎？當然不是。這並非是單純的怕麻煩，更重要的是，我們需要進行持久化的是物件，而不是傳統意義上的「資料」，畢竟我們要打造的系統是乙個物件導向的系統。按照傳統方法繪製e-r圖未必能夠設計出真正符合系統需要的資料庫。既然如此，我們就完全有理由按照物件導向的思路繼續走下去。此時的我們真正需要做的是繪製乙個持久模型，借助它我們完全可以把物件對映到關聯式資料庫。
要把物件對映到關聯式資料庫其實很簡單，我們只需要一些基本的技巧，簡單的說，有如下幾項∶
把屬性對映到列；
把類對映到表；
在關聯式資料庫中「實現繼承」；
對映關聯、聚合和組合。
把屬性對映到列
類的乙個屬性可以對映到一列，也可能需要對映到多個列，當然也可能需要把多個屬性對映到表的一列。但是通常都只需要把乙個屬性對映到乙個列。另外，並非所有的屬性都需要持久化。比如，有一些屬性完全可以當成計算列來處理。
把類對映到表
把類對映到表。這句話看起來比較容易理解，但是卻容易讓人產生誤解。有些人可能會誤以為乙個類就應該對映到一張表。但是這並不總是正確的。實際上這種一一對應並不是總那麼靈驗。有些時候乙個類也需要對映成多個表，而另一些時候多個類卻也可以對映成一張表。這需要一些經驗，需要具體問題具體分析。
在關聯式資料庫中「實現繼承」
這當然是不可能的。前面已經反覆提到過，關聯式資料庫不可能支援繼承。這個問題的本質是，當把類對映到表的時候，如何解決那些存在泛化關係的類。我們有三個方法應對這種問題，都不複雜。三種方法各有憂略，沒有哪一種是十全十美的。我們不妨通過例項來理解這些方法。
首先，我們看到這樣一張類圖：
圖1：三個要對映到關係模型的類
人類顯然是乙個抽象類，類名是斜體字。它有兩個子類，學生和教授。學生類只有乙個屬性，成績。同樣教授類也只有乙個屬性，工資。我們忽略掉方法，因為和我們要討論的問題無關。我們要把這樣乙個類層次對映到關聯式資料庫有三種方法可以選擇。
方法一：對整個類層次使用乙個資料實體
說得明白點就是把三個類影射到同一張資料表裡面去，三個類的所有屬性都對映成同一張表裡的列。就像圖二這樣。
圖2：對整個類層次使用同乙個資料實體（這不是類圖，儘管看起來很像）
這個方法很簡單。這個錶用起來也很方便。但是，我不說大家也知道。簡單的東西往往都有一些小缺憾。浪費空間是顯而易見的，即使我們只有三個類。但是設想一下如果我們有五個十個甚至更多的類，它們之間存在繼承關係，的時候，這樣作會怎麼樣。那樣對空間的浪費真的是可怕的。另外，如果某乙個類增加了乙個屬性，那麼表就要增加乙個屬性，這樣實際上影響了三個類的物件。如果增加單個屬性時發生了錯誤，會影響整個層次中的所有類。這種錯誤一旦在程式執行過程中發作，你可能根本摸不到頭腦，它們真的非常隱蔽，令人難以察覺。
方法二：每個具體類都使用乙個資料體
每個具體類都會被對映到一張表。所謂具體類，在本例中，是指「學生」和「教授」類，當然不包括抽象類「人」。每個表代表著乙個類，它包含那個類的所有必須的屬性，更重要的是它包含了那個類的繼承屬性。如圖3所示。
圖3：每個具體類都使用乙個資料體（這不是類圖，儘管看起來很像）
這種方法同樣有乙個顯著的缺點，如果需要修改乙個類，那就必須修改它的表和所有子表。另外，如果有乙個人即是學生又是教授的時候就比較麻煩了。這樣需要在兩個表裡面分別儲存同乙個人的記錄。而且這個人會有乙個學生編號和乙個教授編號。有一些時候，可能這是無法容忍的。
方法三：每個類使用乙個資料實體
為每乙個類建立一張表。子類的表的主鍵同時作為外來鍵。如下圖：
圖4：每個類使用乙個資料實體（這不是類圖，儘管看起來很像）
我最喜歡這種方式，因為這樣最符合物件導向的概念。某乙個類發生變化時，也很容易修改相應的表。但是，缺點是資料庫裡面會有很多表。讀寫資料的效率可能會有一些慢。另外，採用這種方法還要注意靈活使用檢視。正如前面所說的那樣，沒有任何乙個方法是十全十美的。究竟選擇哪種方法，需要在實踐過程中具體問題具體分析，擇其善者而從之。
對映關聯、聚合和組合
僅僅把類對映到表，屬性對映到列，這樣顯然是不夠的。與此同時還必須把類之間的關係對映到關聯式資料庫裡面。類之間的關係無非就是繼承、關聯、聚合、組合。繼承剛才已經單獨討論，現在就來看關聯、聚合和組合是如何對映到關係模型中去的。
使用外來鍵在關聯式資料庫實現類之間關聯
可以使用外來鍵在關聯式資料庫中實現關聯。比如，存在這樣一種關聯關係，「乙個雇員工作在乙個崗位上」。類圖顯然應該如下圖所示：
圖5：乙個雇員工作在乙個崗位上
在關聯式資料庫裡，可以在雇員表上新增乙個外來鍵，像下圖這樣。
圖6：在雇員表上新增乙個外來鍵（不是類圖，儘管看起來很像）
通過關聯表在關聯式資料庫實現類之間的多對多關聯
假設存在這樣一種常見的關聯，「乙個騎士可以騎多匹馬，每匹馬也可以由多名騎士來騎」。類圖如下：
圖7：乙個騎士可以騎多匹馬，每匹馬也可以由多名騎士來騎
在關聯式資料庫上加乙個關聯表來表示兩個類之間多對多的關聯關係。
圖8：使用關聯表表示類之間多對多關聯關係
使用以上介紹的技巧，完全可以把持久物件有效對映到關聯式資料庫裡面。根據我自己的嘗試，這的確是乙個有效的方法。如果大家感興趣不妨在實踐中嘗試一下。
InnoDB引擎 事務永續性
事務是指構成單一邏輯工作單元的操作的集合。資料庫系統維護事務的acid四個特性 先從永續性說起。保證永續性的策略就是write ahead logging。在事務提交之前，備份乙份事務的操作日誌在磁碟上，備份成功再允許事務成功提交。innodb引擎中支援永續性的是redo log，redo log寫...
SQLServer 延遲事務永續性
sql server 2014新功能 延遲事務永續性 delayed transaction durability sql server事務提交預設是完全永續性的 full durable 從sql server 2014開始，增加了新的功能延遲事務永續性，使得事務提交可設定為延時永續性的 dela...
Hibernate的Spring永續性
15章，441頁，38 99 本書僅供初學者使用，但是更有經驗的開發人員可以學習一兩個東西 本書涵蓋了hibernate和spring與永續性的關係 本書的範圍使它變得非常有趣。許多書籍談論hibernate，許多書籍談論spring。但是，我不知道有多少人在永續性方面談論兩者的使用。在沒有描述交易...