比如在乙個大型的手機銷售公司有這樣的一種部門崗位結構：
現在有下面的需求
1>要求給使用者分配許可權時用蘋果部門經理、諾基亞部門經理…而不是部門經理這樣的崗位；
2>要求統計蘋果部門經理、諾基亞部門經理的銷售業績；
當有上面這些需求時，上篇隨筆中的許可權模型就無法滿足需求。
我們先不考慮部門資訊，這樣上面的結構圖中就只剩下崗位資訊。對這樣的需求建模，第乙個反應是將崗位(post)建成樹形結構。但是這樣一來，蘋果部門經理與諾基亞部門經理就是兩個完全不同的角色與資源實體關聯，並且關聯關係是相同的，這樣就造成資料冗餘。如果崗位結構很小，這樣做也未嘗不可。cdm：
這個許可權模型與之前的模型並無多大差別，只是將崗位做成了樹形結構，以適應新的需求。
3.2但是如果組織結構圖很大，崗位實體與崗位許可權實體也會變的很大，在配置許可權時也會很麻煩。
在組織結構圖中，我們看到蘋果部門經理和諾基亞部門經理所處的崗位級別是一樣的，也就是說它們是部門經理的乙個例項。依此類推，**銷售人員是銷售員的例項。所以有乙個崗位例項的實體，並且它們有乙個子父節的關係。最後，可以將崗位例項分配給使用者。cdm:
postorganization:儲存崗位例項的資訊，即儲存上面的崗位結構圖。
3.3 加上部門的資訊
累了，先直接上圖，不解釋》.
在這個模型中，可以解決這樣的需求：當蘋果部門有新的客戶時，可以郵件通知部門內所有的人。
本次，主要討論將組織結構的資訊加入到許可權系統中。本篇文章僅是拋磚引玉，有什麼不對的，不足的，想法片面的地方，還望各位指點指點
MySQL資料庫系列之資料庫設計原則
mysql中資料庫設計原則 1.一般情況下，應該盡量使用可以正確儲存資料的最小資料型別。資料型別不一樣，儲存的執行效率也不一樣。最好使用適度的整型資料型別，例如int之類的資料，這樣在做查詢或者字段排序的時候速度是最快的。2.盡量避免null值的時候，因為這樣會增加資料庫處理的開銷。但是也要考慮實際...
資料庫結構的設計
如果不能設計乙個合理的資料庫模型，不僅會增加客戶端和伺服器段程式的程式設計和維護的難度，而且將會影響系統實際執行的效能。所以，在乙個系統開始實施之前，完備的資料庫模型的設計是必須的。在乙個系統分析 設計階段，因為資料量較小，負荷較低，我們往往只注意到功能的實現，而很難注意到效能的薄弱之處，等到系統投...
資料庫設計文件結構
本章節主要是對系統的背景和需要要完成的主要功能的大體介紹。需求分析就是分析使用者的要求。通過詳細調查現實世界要處理的物件 組織，部門，企業等 充分了解原系統的工作概況，明確使用者的各種需求，然後在此基礎上確定新系統的功能。新系統必須充分考慮今後可能的擴充和改變，不能僅僅按當前應用需求來設計資料庫。把...