僅是一點考慮，不成熟也不足為借鑑？希望大家參與討論。
在建立資料庫的時候經常遇到實體之間存在繼承關係。
對於簡單的繼承在處理的時候往往不考慮這一點，最常見的就是人員資訊管理，以教學管理系統為例，並不抽象出人，而是直接將學生、教師作為不同的實體。同時也不區分出男人和女人。
然而在有些地方，不考慮實體間的繼承關係則會帶來資訊的冗餘。比如煤礦地質資訊中鑽孔、見煤點和夾矸三類資料之間存在著繼承關係，鑽孔資料具有座標位置；煤礦裝置設施管理資料庫中採購裝置資訊（庫存裝置）與正在執行裝置、檢修裝置、報廢裝置存在繼承關係，而正在執行裝置則具有空間位置資訊。這是兩類很典型的情況。後者更為複雜，裝置存在乙個生命週期，改變裝置的使用狀態將產生乙個事務。舉例來說將當正在執行裝置出現故障需要檢修時，需要刪除正在執行裝置表中的資訊，在檢修裝置表中增加資訊
建立和使用空間資料庫的傳統觀點「這個地方有什麼」，基於空間位置和幾何圖形；而物件資料庫則考慮的是「什麼在什麼地方」，將空間位置和幾何圖形僅作為它的屬性。這在資料編輯的時候表現出明顯的差異，基於空間位置和幾何圖形的空間資料庫以圖形作為編輯的中心，屬性新增在圖形產生之後。而基於物件的方式思考則是先產生物件後有位置。
繼承關係可視為一種特殊的依賴關係，在建立表的時候，物件的構造過程類似，必須首先構造父類物件，對父類所具有的屬性賦值，再對子類的屬性賦值。
目前常見的管理方式是將空間資料和非空間資料分開儲存。將井下正在執行的裝置設施儲存為gis的圖層資料，以屬性表的方式管理相關資訊。在程式端實現資料的整合，在給圖層資料編輯的時候呼叫相關的非空間資料庫資訊，通過這種方式來實現空間和非空間資料的一致性。增加空間資訊相對容易，但是在刪除空間資料的時候操作就顯的很複雜。多數情況下還需要手動更新相關的非空間資料庫資訊。造成工作的重複。
因此裝置設施管理中空間和非空間資料一體化管理和簡化資料編輯工作的需求非常迫切。煤礦部門使用者的計算機水平普遍低，因此資料的重複錄入是難以接受的。基本思想史載父表中進行裝置的狀態的修改，同時自動更新相應的子表，比如將備用裝置的狀態更改為檢修裝置，同時需要更新備用裝置表和裝置檢修表。這樣是用空間資料庫和關聯式資料庫一起用的解決方案。可以充分利用關聯式資料庫事務處理的強大功能。
還有一種思路是使用者在編輯資料庫產生事務（操作多個關聯表）的時候並不採用自動更新，而是記錄相關的事務序列，提公升使用者必須完成相應的事務，保持資訊的同步。參照完整性可以保證刪除時候表資訊的一致性。事務日誌表應該記錄下面的資訊：使用者操作，操作型別，物件表，事務狀態，執行時間，使用者。對使用者的操作型別要做一些分類和細化。
這裡還沒有考慮這樣乙個問題，如何檢視執行裝置、檢修裝置歷史資訊？上面的都是現階段的使用狀態。
胡言亂語 JAVA NIO的價值
mina2.0框架在實際的測試過程中，發現在併發量很大的情況下，mina框架的效能下降的很快。我想這主要與nio的使用有關，mina框架由於復用了執行緒，因此執行緒狀態的切換勢必變得非常頻繁，這對邏輯處理很短暫的應用來說是乙個很大的消耗 邏輯處理時間短意味著執行緒狀態之間的切換很快 我想mina2....
關於團隊管理的胡言亂語
我們專案不算複雜，乙個專案經理，乙個美工，兩個頁面，乙個應用程式，這些都工作在.net平台，然後在加上乙個linux平台的小組長，四個linux平台的開發，一名專職測試。十個人的班子就這樣搭建起來了。專案經理做頁面出生，對業務很了解，直接對接客戶和公司的市場人員，手下的兩個頁面人員也是他一手帶起來的...
間歇性的胡言亂語
我把童年丟了，把青春掉了，去換取乙個名叫成就的東西 我把父母扔了，把自己丟了，去尋找乙個叫愛情的東西。這句話不知怎麼的就打動了我，也許和這句話的內容不相干，但是我就是想到了這些 有時候真想什麼都不管，就這麼墮落下去，怎麼開心怎麼玩，怎麼放鬆怎麼做，可是最後，放不下，前面那麼多的努力說放棄就放棄，實在...