Serendipity 喺處埋 categories 方面與 WordPress 截然不同, Serendipity 有專門處理 category 既 tables: entry 同埋 entry_cat; 而 WordPress 就有簡單d, 將 category 歸納入去 wp_terms, wp_term_relationships 同埋 wp_term_taxonomy 入面, 與 tags 及 link categories 等共存。 結果就係 WordPress 只係用 10個 tables 就完成任務, 而 Serendipity 裝咗 tags plugin 之後就成 27個 tables, 足足多左差唔多 3倍。

Serendipity 既 database design, 只能滿足處理 category:

而 WordPress 既 database design 就將 category, tag, 同埋 link category 歸納入 term:

結果就係 WordPress 喺 extensibility 方面優於 Serendipity。以 tag 為例, 假如 WordPress 唔支援而又想新增依個 feature, 佢只係要 taxonomy 方面定多個新名, frontend 作出適當修改, backend 甚至可以用原有系統就完成; 相反喺 Serendipity 要新增 tag 依個功能就要開設專門處理 tag 既 tables, 同埋 backend, 如果加一兩種新 feature 尤是可, 若果加十幾項就麻煩了。

以下係我 migrate 既 PHP script:

$result = mysql_query('SELECT c.categoryid, title FROM serendipity_entries e INNER JOIN serendipity_entrycat c ON c.ent
while ($post = mysql_fetch_assoc($result)) {
// category mapping
        switch ($post['categoryid']) {
                case 3: $new_cat = 8; break;
                case 2: $new_cat = 11; break;
                case 12: $new_cat = 12; break;
                case 1: $new_cat = 9; break;
                case 16: $new_cat = 13; break;
        }
        $query = "SELECT  id FROM wp_posts WHERE post_title = '$post[title]'";
        $r2 = mysql_query($query, $wp);
        $row = mysql_fetch_row($r2);
        $wp_post_id = $row[0];
 
      mysql_query("UPDATE wp_term_relationships SET term_taxonomy_id=$new_cat WHERE object_id=$wp_post_id");
 
      mysql_query("UPDATE wp_term_taxonomy SET count = count - 1 WHERE term_taxonomy_id=1", $wp);
      mysql_query("UPDATE wp_term_taxonomy SET count = count + 1 WHERE term_taxonomy_id=$new_cat", $wp);
}

MSSQL: sp_database
MySQL: show databases

好明顯唔記得到估到或者接到 MySQL 既 command, 至於 Sybase, 一d 基本既 commands 都冇(或者我唔知), 例如要列出表格:

MSSQL: sp_help
MySQL: show tables
Sybase: 係佢個 client program 度 press F7…

至於顯示欄:

MSSQL: sp_help tablename
MySQL: describe tablename
Sybase: 係 F7個畫面 click Show Columns

參考

未等量化之前:

Table: Product

id

category_name

SELECT category_name FROM product

等量化後:

Table: Product id idcategory

many to one

Table: Category id name

SELECT c.name AS category_name FROM product p INNER JOIN category c ON p.idcategory = c.id

條 query 長左好多, 但係好處都好多, 首先若果你個 category 名係水蛇春咁長的話, 而又有好多 product 都將個咁長既 category 名放係 category_name 度, 咁你d 資料重複左好多次, 浪費好多位。

同時, 你要更新個 category 名既話, 就要更新好多個 product 既 category name, 時間上方面會慢左。而且若果你只係改左一個 product 既 category name, 其他既 product 都會繼續用舊 category name, 即係管理上面都麻煩左。 若果你 normalize 左佢就冇晒依d 煩野。

非等量化

最近攪緊個網站流量越黎越大, 以前 design 既時候冇預到流量升得咁既程度, 於時乎用左比較多 normalization。

之但係頭先先話完 normalization 好, 點解而家又話用得多左? 因地制宜, 以 MySQL 為例, 開一個 table 即係開一個 file, 若果你完全 normalization, 佢就要同時開好多個 file 搵資料, 雖然其他 table 度搵出黎既資料會 cache 黎增加效率, 但係都要假定你有足夠記憶體先得, 使用記憶體既同時, CPU 既使用量又會增加。

以我經驗, peak hour 時未非等量化之前, CPU 使用量係 30%, 非等量化之後就係 3%!

多語系的非等量化

等量化對d 同時支援多語系既網站特別有用, 而implemntation 方面, 係 code project 有更詳細介紹。

不過我都預計到個流量有返咁上下, 所以冇等量化語言, 反而開多幾個 column, 然後用 AS 依個 keyword, 咁係 presentation level 就唔需要改動任何野都可以好輕鬆咁做到多語系 (ASP.NET):

• Default.aspx.en.resx 入面有條叫 SQL1 既 string resource
  SELECT name_en AS name FROM product
• Default.aspx.zh-HK.resx 入面有條叫 SQL1 既 string resource
  SELECT name_zh_hk AS name FROM product

係個 Default.aspx 度:

<neo:MySqlDataSource SelectCommand="<%$ Resources: SQL1 %>" runt="server" ID="MySQL1" ConnectionString="<%$ConnectionStrings: Default%>" />

<asp:DataList DataSourceID="MySQL1" runat="server" ID="DataList1" >

<ItemTemplate>

<%# Eval("name") %>

</ItemTemplate>

</asp:DataList>

只要你個 page 既 culture set 岩, 咁就可以自動用到以上咁方面既功能, 甚至乎我個 MySqlDataSource 可以自動依據 culture 黎改 keyword 既 field, 咁就唔駛用到兩條 SQL 分別放係唔同既 resource file 度, 不過我有其他原因而冇咁做到。

Materialized View

之前提及過, denormalization 會有資料改動時遺漏既可能性, 咁使用 materilized view 就可以解決依個問題。不過, 速度上係 update 時都係冇提高到, 所以 nor 唔 normalize 都要睇情況, 而更重要既, 係我用緊既 MySQL 5.0 係唔 support materialized view, 相信要等到 6.0 或更後先 support。現時只有 Oracle 8 或以上先正提供, 其他就要用一大堆 triggers 先做得到, 諗起都煩, 所以都係不用為妙。

我都算保守, 冇一次過轉晒, 而係分階段轉。