本人偶然間想到，google了半天也沒有找到相似的東西。在此拋磚引玉，望各位不吝賜教。
資訊唯一性原則是解耦合與促進一致性的資料結構設計方法。乙個資訊只出現一次，其他地方只是引用。
比如客戶買書《***》這一業務，需要進行兩次相關操作，即書店將《***》這種書的數量減1，客戶賬戶中《***》這種書的數量加1。需要注意，這裡是《***》，是指乙個種類，後面建模時提到的《***》是具體的賣出的那一本。
這個過程缺一不可，如果只讓書店減1，忘記了客戶加1，則客戶買不到書；反之，則是賣出的數量會超過書店的存貨。
在資料庫領域，採用acid方式來解決，就是事務。將書店減1和客戶加1看作乙個整體，其中乙個操作失敗，就算這兩個操作整體失敗。這樣可以保證一致性。
你會發現，這一業務中，資料需要從兩處地方配合起來說明買賣的數量。這就產生了乙個耦合。但通常我們認為這種耦合是天經地義的。
不過，耦合就意味著大量驗證，保持資訊唯一性原則或許可以減輕驗證的負擔。
經過分析，我們發現，這裡的加1減1實際上是買賣的那本《***》書的數量屬性。上面在處理業務時將賣出的那本《***》書忽略掉了，只將他其中的乙個屬性儲存在了變數中。
在整個買賣過程中，《***》書的交換，其本質是賣出那本《***》書的所有人發生了變化。從書店變為了客戶。
因此，在資訊唯一性原則下，首先要建立賣出《***》書的實體，然後定義其數量和所有人。買賣的過程，就是所有人屬性發生變化了的過程。
這樣，書店的《***》這種書的總數，和客戶的《***》這種書的總數，就從直接影響業務的資料，變成了乙個隨時可以重算的統計結果。他們共同受所有《***》書實體的所有人屬性和數量屬性的影響。
這樣，原來需要acid事務支援的買賣業務，就變成了乙個普通的業務。
同樣的道理，客戶付錢也是一樣。付款可以將人民幣建立乙個實體，其數量就是《***》本書的賣出**（可能會涉及打折等因素，與標價不一致，是每一本賣出《***》書的特有屬性）。
書的交換和錢的交換是同時發生的，但在資訊唯一性原則下並不需要acid支援。如果書的所有人發生了變化，而錢忘記了。則在統計的過程中，應付賬款與已付賬款就有乙個差額，賣家很容易判斷和發現。此時客戶可以再次付款，直到付款成功。反之，錢付了，而書忘了變換所有人，則也有差額，客戶的付款就變為了預付款。客戶可以用這個款項再去買書，直到買到為止。
資訊唯一性原則的本質在於，實事求是的將客觀世界發生的事情告訴計算機，記錄下每乙個與業務相關的現象。這些現象作為計算的基礎。如果計算機忘了處理一些現象，那麼說明其認識的世界是殘缺的，但殘缺的世界也是可解釋和理解的。人類能夠修復其認識上的缺陷，從而保證其正確性。
Oracle唯一性約束和唯一性索引的關係
唯一性約束通過唯一性索引來實現？我覺得這說法不對。對於唯一性約束，索引是必須存在的，唯一性約束本質上是通過索引來保證的，但不一定是唯一性索引。唯一性約束允許有null值，唯一性約束的列可允許有多個null值。唯一性約束通過btree索引實現，而btree索引是不會包含null值，但使用null值過濾...
程式的唯一性
試過各種方法,下面這個相對比較好 在program.cs中,新增如下,紅色字部分要改掉 usingsystem.diagnostics 新增 namespace programunique static class program 應用程式的主入口點。stathread static void ma...
實現UniqueAttribute唯一性約束
using system using system.componentmodel.dataannotations using system.data.entity namespace zwj.tems.base public override boolean isvalid object value...