資料庫表的設計思路

作為一個程式設計師你避免不了要設計資料表，總是一味地根據他人給出的表來寫sql這樣你永遠也得不到成長。所以我現在要來思考如何設計出資料庫表。

那問題來了，如何設計呢？這可是大問題啊...因為我之前就沒怎麼設計過表，我印象中我只設計過一次表，而且那次我記得設計的出了大問題，我要在毫無關聯的兩張表中查出2個有關聯的欄位，你看到這句話肯定很蒙，你一定會想問這欄位到底有沒有關聯啊？有的，關聯確實是有的，但是我設計的時候並沒有把這兩張表關聯上，再加上當時資料庫沒學好，而且就剩三天就要驗收程式了，慌啊，然後請教同學，他給一通操作整好了，我當時也沒多想他到底是如何整好的。這也導致了我對錶的設計還是一頭霧水。

直到最近，我才有了一點想法。這個想法是這麼來的，儘管我不知道表的設計，但是學過MVC框架，我知道MVC框架中必然會有實體，而一張表裡的欄位對應著實體裡的變數，那我們不妨反過來想想，一個實體就對應著一張表，我們設計表不就是設計實體嗎？實體有什麼屬性，表裡自然也就有了什麼欄位。這幾個實體究竟有什麼關聯，以什麼作為關聯的紐帶，這便是我們接下來要考慮的東西，一個實體和另一個實體有沒有可以關聯的欄位？有，好的，那我們給他新增上關聯欄位。沒有？那我們再想想，有沒有哪一個或哪幾個實體能為他們的聯絡牽線搭橋，讓他們聯絡上，如果有的話那這個設計就沒有問題，至少是行得通的設計。如果沒有，則說明這是一個絕對孤立的實體，沒有任何實體能與它產生關聯，那我認為這種情況就不應該存在，你設計出一個完全孤立的實體出來有什麼用？拿來當觀眾嗎？這時你就要想了，這個完全孤立的實體究竟有沒有存在的必要，如果有存在的必要，那就建立中間表，把他們連起來，沒有存在的必要，就想方設法把這個表裡的欄位往其他表裡添。

話又說回來，實體怎麼來？要看你的業務了，業務又從哪裡來？就從專案最開始的階段，需求分析來，所以說需求才是專案的重中之重，不信？你上網搜一搜就會發現，只有需求分析是要多次確認的，有一點不清楚的地方都不行，他有可能導致專案有較大的改動，很可能把之前的努力摧毀掉，所以這個需求分析你一定要做好。

還有一點，屬於我還有疑惑的部分，那就是兩個表的關聯，是關聯兩個表的欄位好，還是建立中間關聯表更好，這個我還不太清楚，或者說這個要看情況而定，也希望大家能夠給予我一些思路。