資料庫對於系統的開發所佔的角色就相當於一台汽車但沒汽油,汽車一樣可以動,可以用手推、用馬拉,這就像沒有資料庫的系統,一樣可以運作,但是要用手記錄過程中的資訊,手動去將資料記錄在紙上或其他地方,這樣來說,這個系統是沒什麼意義的,系統的運作中必然會有資料流的運作,要對資料最常做的幾個動作,包括新增、刪除、修改、查詢,而進一步系統可能要對儲存下來的資料做分析,做成報表,供企業做決策的參考.

因此,以ASP.NET來說,最常使用的對應資料庫就是MS SQL,當然My Sql、Oracle、Sybase、Access...都可能遇到,但以一般最常遇到的MS SQL來說,目前已到了SQL 2008 R2的版本,一般就開發上來說,不太可能寫程式就只寫程式,基本上資料庫的設計,開立TABLE都要能上手,其他諸如資料的匯入匯出也是常用的功能,而卸載附加、備份還原也都是經常使用的功能,這些一般講資料庫的書都會有詳細的說明.

以ASP.NET開發WEB應用程式來說,最切合的當然還是MS SQL,一般建立資料庫時,會先規劃TABLE的關連性,要做基本的正規化,否則系統越來越龐大時,資料表會亂的無法管理,接手維護過的系統,曾有個系統亂到連客戶都不知道如何解釋,最後發現,他一分相同的資料存在好幾個地方,以至要以舊系統為基礎開發一個新的系統時,舊系統的資料庫完全無法參照,連客戶自己也只能用猜的,舉例來說,一個產品名稱,他分別存在產品主資料表、產品明細資料表、銷售資料表、庫存資料表,當變更產品名稱時,要分別去四個資料表做修改,但系統老舊,中間接手過的人好幾個,有的止存了其中二個資料表,有的只存一個,造成系統中的一個產品名稱有新的有舊的,完全找不到頭緒,也完全沒規則,但客戶不明瞭這些資料的關連性,他認為新做的系統,就是要能把這些資料釐清,那真是天方夜譚,無論如何解釋,客戶認為這些視系統能解決的問題,這根本和系統沒關係,錯亂的資料已經運做好幾年了,這是做系統的翻新,不是做魔術表演,誰能做一個讓時光倒流的系統去還原當時的時點,遇到這種冥頑不靈的客戶,老實說,早點散開比較實在,這種情形當然不多,但是遇到了就要快散,若是遇到無厘頭的客戶,又遇到公司搞不清楚狀況的業務,那別多說,就是快散,這種誰接誰倒楣的東西,絕對不要碰,弄得一身腥,沒完沒了,那次的狀況當然最後也知道原因,客戶因為本身是負責那個系統的開山祖師,但是數年前建構時,他本身沒有太多的資訊背景,加上找個便宜的開發人員,最後就用一天算一天,直到數年後,因為資料已經亂到不可收拾,並且已經開始影響到公司的運作,而客戶的上頭也開始追究原因,這時....客戶力爭說系統老舊要重新開發,規避了自己當年的亂規劃的責任,而客戶的上頭也當真認為是因為系統太老了,所以造成資料有問題,系統又不是汽車,開久了還會引擎老舊出問題,所以後來客戶就以更新系統、增加效能為理由,一方面規避自己的責任,一方面有可以當成自己的績效,所以案子就發了,而蠢的是公司的業務,想說怎麼沒人搶,就很高興的搶回來了,那一看就知道是個爛攤子,因此業務接回公司後,誰接了,也就等於誰就被賣了..

上述說明的是,系統的規劃是如何的重要,在規劃初期,底層夠不夠扎實,甚至爾後的擴充性、延展性、整合性,都要考慮,而不是知道個大概就開始建立幾個TABLE,反正建TABLE又不用錢,不夠了就在建,欄位也是一樣,以至於一個資料表有多達八十幾個欄位,要增加新功能,原來的TABLE沒人看得懂,又怕動到原來的功能,因此,新加的功能就增加自己的TABLE,反正新的功能能動,管他原來的TABLE有沒有正規化的問題,如此三五年後,絕對有是一個亂到不行的系統,TABLE與TABLE間,根本無法對應,相同的產品名稱卻有不同的產品代號、不同的庫存品卻又有相同的產品代號..當然,客戶可能又會想說,系統太舊,要弄個新的,重點是,新的系統....資料完全要正確回來,當然他看準了又有很多搶案子搶瘋的業務,一定會有魚上鉤的,然而對他來說是沒風險的,案子合約後來才知道,為什麼要特別註明,舊系統的資料庫的資料,包含無法對應的,到了新系統的資料庫後,要能完全對應上..搶案子搶瘋的業務,他當然不會去想兩個相同代號卻不同名稱的產品,要以哪個為準呢,他會認為這簡單啦,就接了,對於客戶來說這是沒有風險的,頂多就是還是用舊系統,然而新系統合約已註明,舊資料庫對應不到的資料,倒到新資料庫後,要能完全對應上,否則無法結案,這種事情有經驗的技術人員,去和客戶談個兩次,開個兩次會就知道了,當然是打死不接,就算翻臉頂多你去找別人做而已,何必做這種無聊沒意義的案子..

因此,程式架構的規劃、資料庫架構的規劃,牽扯到這個系統將來的命運,常看到有人拿到粗略的規格就拼命寫程式,聽完客戶三言兩語就歸化資料庫,弄到後來只有兩種下場,一個是拼裝車,東拼西湊運氣好結案了,但是將來誰接維護誰倒楣,另一種就是開發到一半已經亂到無藥可救,永遠結不了案,這都是太輕浮和隨性了,系統在還沒完全分析好流程、整個架構的範圍前去實做都是白做工,在還沒做好設計前,就是寫程式,只會亂到不可言喻,底打得好,在去開發都不遲,但往往這不能怪那些技術人員,甚至是無法改變得無窮迴圈,因為狀況外的老闆或經理,常常認為東西拿到就開始趕快做了,加上急迫短暫的時程,要種一顆蘋果樹,又不想先鬆土、施肥、灌溉,將來種出一顆爛蘋果,其實也非常正常.