資料庫設計-中

在資料庫設計-上 我提到資料表正規化的方法，在這一篇要講資料庫設計的工具，資料庫設計的工具有很多，有人擅長使用UML用物件導向的角度分析來建模，也有人喜歡用DFD+ERD來建模，我個人的偏好是後者，這裡並不會分析哪種方法比較好或比較差，而是把重點放在建立出來的資料庫模型能夠符合系統的需求，在系統開發時不會在茫茫資料表中迷失的方法就是好方法。

Rails直接執行SQL command

雖然Rails的ActiveRecord API相當好用，但是真的遇到要對大批資料異動，而且還附帶複雜的Join邏輯時，要想用ActiveRecord來兜出需要的語法就會相當頭痛，相對的也就是簡單的一段SQL command就解決的事，處理起來的performance還比較高，這時也是可以讓Rails直接執行SQL command，只要使用

sql = "update customers as c inner join customers as c1 on c.introduce_id = c1.orig_cust_id set c.referral_cust_id = c1.id where c.introduce_id is not null"
ActiveRecord::Base.connection.execute(sql)
#也可以搭配一個變數來接收回傳值
results = ActiveRecord::Base.connection.execute(sql)

資料庫設計-上

        網路上程式語言的學習資源很多，教SQL的也是一狗票，因為這是Hard skill，按著教程一步一步做就會有一定的成果出來。相對的教資料庫設計這種Soft skill的反倒少了，若把人比做應用系統，那資料庫就是腦子，而資料庫設計就是學習方法了。
        只要設計出來的資料庫能夠符合應用系統現在甚至未來的需求就是好的資料庫設計。但是要符合應用系統的需求說來簡單，要怎麼做卻是很多程式開發新手的心中的痛，常見的情況是在開發系統初期，因為忽略了或過度簡化了資料庫設計，一開始並不覺得哪裡有問題，在開發過程中不斷的為了需求新增資料庫物件，不斷的疊床架屋，到了中後期之後，發現有需求異動了，這時候回頭改才發現建構的資料結構亂如麻，改了一個地方，另一個功能卻爆炸了。因此為了避免這種窘狀的發生，最常見的作法就是繼續的疊床架屋上去，最後交到業主手上的就是一套可以使用但是卻難以維護、資料庫效能日漸低落的系統。

Session 2：從Table擷取資料 （1）

SELECT陳述式被使用來從資料表中擷取資料

Session 1：Database Object

所謂的資料庫物件(Database Object, DB obj)是指資料表(Table)或是檢視表(View)...等，由使用者或系統建立在資料庫中的物件名稱。

Session 0：SQL簡介

• 結構化查詢語言(Structural Query Language, SQL)，是用於關連式資料庫中的標準查詢命令。
• 單純的SQL是對資料庫命令的陳述而不是程式語言，因為它不包含控制命令。
• SQL是由命令、運算子和函式組成的陳述式所構成的，而SQL的目的是對資料庫進行存取動作。
• 市面上知名關聯式資料庫有：Oracle、SQL Server、MySQL、Postgre、SQLite、Access...
• SQL可以細分成五種語言，分別是：