數據庫70多張表設計的一些思考…

昨天在一次研討會上，一同志說他為甘肅某高校做了一個建筑部門的管理網站用了足足70多張表，我一聽一驚，隨口來句，這哥們扯吧！

我認為學校的單個部門業務不論多么復雜，這么多表也并不利于實際系統開發，況且單個部門也不可能有那么復雜的業務。那么站在這哥們的角度理解，理由只有一個，他把表拆分的非常的細致，單個表字段很少，功能非常單一。

好像也可以理解，但是70多個表，俺從業多年幾乎也沒有見過幾個如此龐大的工程。總是感覺怪怪的，于是總想從理論上分析下他的這樣設計是否合理。數據庫設計相信大部分開發人員都知道要遵守設計范式咯，這部分內容可以參考我的上篇范式文章，那么我能否從范式著手，做個分析呢？問題來了，我也有些困惑了，下面講講得出的結論：

范式作為數據庫設計的理論基礎，其實并不完善，有些情況不適合實際開發。范式的指導原則是盡量做到清晰、簡單、明了，把復雜的關系給拆簡單了。但是問題出來了，實際開發要考慮高效，簡捷，盡量避免多表查詢。而這一原則恰恰和范式理論沖突，那么如何去做呢？我想每個人都會有不同的做法，當然最重要的是自己工作經驗的積累，和對實際業務的了解，去設計真正適合自己的數據庫結構。

這是一位高人的說法：

所謂范式指的是設計高效的方便擴展數據庫的準則，但是實際之中也只是作為一個參考，因為按照標準設計范式，查詢很復雜，效率不高，不一定適合實際開發。那么實際的工作之中，對于實際數據庫設計只有一個原則：“根據業務盡可能的減少多表查詢”。

?

最后，對于70多張表的哥們來說，只能說符合范式的簡單化，但是實際中70多個表的多表聯合查詢對于開發人員來說并不是一個good idea。

?

歡迎大家一起討論…

?

總結

以上是生活随笔為你收集整理的数据库70多张表设计的一些思考…的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。