資料庫表的設計思路
作為一個程式設計師你避免不了要設計資料表,總是一味地根據他人給出的表來寫sql這樣你永遠也得不到成長。所以我現在要來思考如何設計出資料庫表。
那問題來了,如何設計呢?這可是大問題啊...因為我之前就沒怎麼設計過表,我印象中我只設計過一次表,而且那次我記得設計的出了大問題,我要在毫無關聯的兩張表中查出2個有關聯的欄位,你看到這句話肯定很蒙,你一定會想問這欄位到底有沒有關聯啊?有的,關聯確實是有的,但是我設計的時候並沒有把這兩張表關聯上,再加上當時資料庫沒學好,而且就剩三天就要驗收程式了,慌啊,然後請教同學,他給一通操作整好了,我當時也沒多想他到底是如何整好的。這也導致了我對錶的設計還是一頭霧水。
直到最近,我才有了一點想法。這個想法是這麼來的,儘管我不知道表的設計,但是學過MVC框架,我知道MVC框架中必然會有實體,而一張表裡的欄位對應著實體裡的變數,那我們不妨反過來想想,一個實體就對應著一張表,我們設計表不就是設計實體嗎?實體有什麼屬性,表裡自然也就有了什麼欄位。這幾個實體究竟有什麼關聯,以什麼作為關聯的紐帶,這便是我們接下來要考慮的東西,一個實體和另一個實體有沒有可以關聯的欄位?有,好的,那我們給他新增上關聯欄位。沒有?那我們再想想,有沒有哪一個或哪幾個實體能為他們的聯絡牽線搭橋,讓他們聯絡上,如果有的話那這個設計就沒有問題,至少是行得通的設計。如果沒有,則說明這是一個絕對孤立的實體,沒有任何實體能與它產生關聯,那我認為這種情況就不應該存在,你設計出一個完全孤立的實體出來有什麼用?拿來當觀眾嗎?這時你就要想了,這個完全孤立的實體究竟有沒有存在的必要,如果有存在的必要,那就建立中間表,把他們連起來,沒有存在的必要,就想方設法把這個表裡的欄位往其他表裡添。
話又說回來,實體怎麼來?要看你的業務了,業務又從哪裡來?就從專案最開始的階段,需求分析來,所以說需求才是專案的重中之重,不信?你上網搜一搜就會發現,只有需求分析是要多次確認的,有一點不清楚的地方都不行,他有可能導致專案有較大的改動,很可能把之前的努力摧毀掉,所以這個需求分析你一定要做好。
還有一點,屬於我還有疑惑的部分,那就是兩個表的關聯,是關聯兩個表的欄位好,還是建立中間關聯表更好,這個我還不太清楚,或者說這個要看情況而定,也希望大家能夠給予我一些思路。