先說說我對easydbo的一些個人的看法，easydbo是乙個超輕量級的目前只支援單錶 對映的持久化框架，超輕量意味著入手很簡單，使用很方便，但注意它是單錶對映，導致在處理一些對映關係的時候要做一些特別的處理。在這裡我說一些個人在使 用easydbo對一般持久化策略的愚見。
一對一
一對一關係要分為兩種情況，一是主表對從表的映 射。如name(firstname, lastname, midnmae) 表和user表，因為easydbo只支援單錶的對映，如果表的粒度過 細，會導致極細的領域物件的產生，如name物件的產生，而又需要為這些細粒度的物件建立crud方法，而且easydbo沒有象hibernate那樣 的自動的關聯持久化操作，而且如果不使用easyjf-dbo.xml來配置的話（即直接使用類實現iobject介面的話），你甚至不能在user物件 中出現name物件的私有成員申明。所以在這種情況下，最好把name表和user表融合。二是大表和大表的對映，在這種情況下就只有使用外來鍵關聯的策 略。但同樣要注意，easydbo現在還不是乙個完善的持久化框架，我認為很重要的一點就是離開了easyjf-dbo.xml的配置來持久化物件，如果 直接使用implements iobject（而這是我認為最方便簡單的使用途徑，想必用慣了hibernate轉而使用easydbo的人都用這種感 覺吧）你不能完整的使用oo，即不能在bbsdoc中出現private bbsdir bbsdir;而只能使用 private string bbsdir_id。
一對多
一對多（多對一）通過上面的分析，可 只在這種情況下，最好還是使用外來鍵的關聯（多的一方主動關聯一的一方）。那麼在領域類為一的一方中，不能出現***set之類（如果使用配置檔案除外）。 這樣實現的就是單向關聯。要使用雙向關聯的話，就只能為一的一方新增乙個util類，使用query方法來得到多的一方的list了。
多對多
多對多的情況是比較複雜的了。一般的情況是通過建立乙個中間表來管理兩物件的關係。在easydbo中就分兩個情況了。先舉個例子：比如user和 role，這是乙個典型的多對多的對映關係，在使用者許可權管理模型中這種實現方法很普通。那麼對這個多對多該怎麼處理？首先還是要建立乙個user- role表，這個是必須的，其次就出現了兩個情況，一，直接使用user-role表。這種情況就是說不對user-role表做任何處理，在 userutil中建立乙個list getroles（）方法，在該方法中直接使用sql語句從做乙個兩層的巢狀查詢。這種方法還是不錯，對於原來就使 用jdbc的程式設計師很熟悉，但比較麻煩而且查詢次數較多。另乙個就是為user-role表建立乙個userrole物件，這也是我推薦的做法。建立乙個 物件的意思不是說就是乙個單純的建立乙個橋梁物件（我自己就這樣叫那種為只起中間過度作用的表建立的物件），我就想能不能根據實際的情況利用好這個物件。 比如在使用者許可權管理介面中我們會列出某個使用者的所有許可權或者列出屬於乙個許可權組的所有使用者隻類的，那麼我門就可以在user-role表（即 userrole物件中）新增一些冗餘字段，如username, rolenmae等等來方便頁面的合成操作，比如我門可以方便的使 用# foreach ( $userrole in $userrolelist)… $!userrole.username等等來簡化頁面的編 寫，而且這樣操作，查詢資料庫的次數會少很多，而如果使用第一中就比較麻煩了。但要注意的是不能過多的新增字段，畢竟這些是冗餘的資料。
談談資料庫索引
索引是乙個單獨的 儲存在磁碟上的資料庫結構，他們包含對資料庫裡所有記錄的引用指標。或者索引是對資料庫表中一列或多列的值進行排序的一種結構。索引的作用 提高資料庫查詢的效率。索引支援hash和b tree結構 hash 可以快速的精確查詢，但是不支援範圍查詢。所以hash索引適用於等值查詢的場景，也就...
談談資料庫事務
首先事務用一句簡單的話來說，事務就是邏輯上的操作，要麼都執行要麼都不執行。如最常見的轉賬。那麼事務是如何來保證這種操作的呢？一 事務的acid 原子性 事務視為乙個整體要麼全部成功要麼全部失敗。以轉賬為例子 在事務中的扣款和價款兩條語句。在資料庫管理系統中，預設情況下一條sql就是乙個單獨的事務，事...
利用資料庫來解決我冗繁的資料處理
周五，咱部門秘書找到我，給了我乙個 格式如下，整整有668行記錄，告訴我說，現在如下這個 裡部門名稱是公司名稱，並不是員工所在的部門具體名稱，請給以下 再添一列，補上其員工所在的具體部門名稱.請我務必幫忙，因為若手工一條一條增加這668行記錄一列為這些員工們填上具體部門名稱，估計人得瘋掉。同時領導等...