Map 功能用到的 Drupal 資料

Map 功能是最先開發的部分，所以資料庫的部分是沿用一開始明宗與漢卿他們所建立的生活資訊平台，目前此平台的資料表共有121個，但實際上在拉需求的資料時，會使用到的資料表並不多，而且位置有固定的模式，這個部分請參考 關於Drupal新增content時的資料表變動

node_revisions :

• nid : 應該是 node id ，值通常與 vid 相同，經過一段時間觀察，大部分所需擷取的資料都可以使用 nid 當成唯一鍵。(此部分為觀察結果後的判斷，並沒有細看 drupal 的原碼)
  
• uid :此部分為 Drupal 的使用者 id ，如果需要使用者資料與 uid 的關聯，可以參考 users 資料表，至於身份的部分可以參考 users_roles 以及 role 此兩個資料表；users_roles 負責 uid 與 rid 的對應，role 資料表可查詢到 rid 所對應到的使用者權限身份；而實際上每個使用者權限身份可以執行的動作則位於 permission 資料表。
  
• title : 每個 PO 文的標題。因為整個系統的開發過程與一般先規畫資料庫再寫 AP 這樣的過程稍微不同。雖然在規畫時同樣需要定義出需求哪些資料，但是這邊所規畫出來的資料，未來會放在資料庫的哪個位置或是如何命名則是由 drupal 所決定；這裡所規畫出來的資料就是直接呈現於畫面上的資料。或許這樣解釋不是很清楚，這邊舉個例子，假設在平台上顯示了【系所 : 資訊工程學系】，那這個資訊工程學系的字串資料就是存在於 title 這個欄位，而資訊工程學系的詳細介紹就會存放在 body 欄位。

node :

• type : 此處標示著每個發佈的文章是屬於哪種類型，類型可以是建築物、單位、餐廳等，而這些類型必須在規劃資料時盡量的分類清楚，因為 drupal 上的這些類型並無法向規劃資料庫一樣直接給它們關聯，所以一不小心可能會照成大量的資料重覆存在於資料庫中，或是需要利用非常大量的 sql 語法才能取出資料；雖然 drupal 利用了 nid 將每個資料給予唯一的值，但是重覆的資料過多會導致開發者從不個地方取得資料，也會產生難以維護的問題。至於每個類型內包含著哪些資料則是存放在另外的資料表中。

content_* : 以 content 開頭的資料表則是存放著不同類型資料的內容。

• content_type_unitsmap : 在這邊包含了學校內所有單位等相關資料。此處並不包含單位名稱，單位名稱須利用這裡的 nid 與 node.nid 做比對之後，再取 node.title 才是單位名稱。
  
  • field_um_seat_value : 單位位於哪棟大樓
  • field_um_phone_value : 電話
  • field_um_fax_value : 傳真
  • field_um_mail_value : e-mail
  • field_um_member_value : 包含成員及部分單位簡介也顯示於此
  • field_um_floor_value : 位於幾樓
  • field_um_room_value :單位房間號碼
  • field_um_link_url : 網頁網址
• content_type_sightseeing : 包含景點簡介等資訊，基本上與 content_type_unitsmap 類似。

• content_type_foodnews : 包含餐廳的資訊，基本上與 content_type_unitsmap 類似。

location : 地圖所需要的經緯度存放於此資料表中，所以當利用 content_type_unitsmap 取得單位資料時，也必須利用 nid 與此資料表的 nid 做比對，取出單位的經緯度。

Map 功能所用到的資料，大致上存放在上面介紹的資料表中，當然這個平台還提供了許多其他的資訊可以取用，不過目前只使用了這些資料。除此之外，這個平台當初規劃並非為了 UCampus做準備，所以有許多的分類顯得雜亂，如需要取得特定資訊必須額外再做判斷，這將使得運算資源白白浪費。所以之後規畫了另一個平台 Mobile Service，平台內資訊分類較為詳盡，除此之外也可以提供後台讓未來的各單位發佈新聞活動等訊息 (此部分由 漢卿 所建構，著實感謝)；而對於 Mobile Service 的資料分類將於另外一篇做記錄，以避免資訊混雜。