自從接觸到用PowerDesigner做數據庫建模後，喜歡它就停不下來了。我發現現在很多2-20人的團隊在做數據庫結構設計時，還是會直接在phpmyadmin 或 navicat 裡直接建表。這種直接建表的方式一開始看似節約時間，但當表多了，頻繁變更表結構，需要講表邏輯時，就不比用建模的方式方便直觀。
直接建表的方式還會很容易導致，不同的程序員實現不同功能時，自己建自己的表，導致數據庫表結構混亂，沒有一個人是全部知道這些表的清晰邏輯。
使用PowerDesigner來做數據庫建模，一般都是由一個專門的人來建表維護，開發過程中如果遇到需求改動表結構，也是交給專門維護的人去改動，這樣就有一個能把控全局的人了。
邏輯結構模型-實體
為了方便導出同步物理表結構，我做數據庫建模時都不做實體之間的外鍵約束關係，直接在實體裡添加對應同名的字段，加上註釋。如果在實體之間都做上實體的關聯關係，一是實體多了，關聯關係線也多了，看起來總感覺眼花繚亂。二是導出的 sql 腳本同步到物理數據庫裡，很容易因為外鍵的約束關係和原來的數據表數據有不完整性，導致同步報錯。
PowerDesigner是一個非常強大的建模工具，除了做數據建建模，還能做需求分析、UML建模。由於我自己對UML建模這塊的知識缺乏，一直都想提升自己，總是沒找到提升的理由（或許我不想寫代碼的時候，有手下人寫，我會提升到UML建模的方式），呵呵。
這裡我說說我的一個觀點，讓大家批評指正一下。我總感覺數據庫建模，UML建模，這類開發方式在 Java 和 .net 團隊應用的比較多。PHP 團隊很少用，都是直接上來就擼碼了。
用PowerDesigner做數據庫建模，已經成為我的習慣，就算自己一個人做項目，數據建模是我的必備開發流程。我曾經因為人家公司的開發組裡沒有人用數據庫建模，誰寫代碼，誰建表而默默選擇離職，現在回想起來，覺得自己那時真是年輕不懂事。
邏輯結構模型-實體的屬性
閱讀更多 墨魚碼 的文章
