推 knockout:語法可能麻煩了點，但降子做程式效能比較好~~ :) 07/18 14:33
推 pakker:正規化後效能變好??? 正規化只是減少資料重覆吧 07/18 19:28
→ pakker:一個欄位用bit處理 和一堆table互相join 差很多吧 07/18 19:29
推 knockout:比起有關連性的TABLE 做JOIN 跟一個TABLE做條件式搜尋~~ 07/19 01:08
→ knockout:前者 快多了 ... 07/19 01:09
※ 引述《derekhsu (斷頭不過碗大疤)》之銘言：
: ※ 引述《dinos (守護神)》之銘言：
: : 順道問一下，若是 relation 超過 64 種，那 relation 要怎麼處理比較好呢？
: : 用 char binary 嗎？
: 有一個比較快的方法，直接作第三階正規化把Ralational Table建出來：
: 這需要三個Table，例：
: 1.PEOPLE 紀錄人員
: [ID], NAME, .....
: 2.RELATION 記錄關係的種類
: [ID], RELATION
: 3.RELATION_PEOPLE 紀錄人與人間關係的關聯資料表
: [PEOPLE_ID_SOURCE].[PEOPLE_ID_TARGET],[RELATION_ID]
: 建出來的表比較複雜，但其實是比較符合正規化原則，也比較好進行操作的
但是當要輸出一份清單時，指另會變得很麻煩吧
ex: 輸出與小明有同學關係的通訊錄清單
===================
小華 02-23456789
小莉 03-4567909
..................
===================
又或輸出一份所有關係人的清單
===================
小明 小華(同學)、小莉(同學,親戚)、小張(同事)
小莉 小明(同學,親戚)、小張(同事)
小華 小張(同學)、小明(同學)
小張 小莉(同事)、小華(同學)
..................
===================
--
徵一起游泳的朋友
地點: 內湖焚化爐游泳池 http://www.nhrip.tcg.gov.tw/07_faq/01.htm
(Wed. Fri. Sun.) or (Tue. Thu. Sat.) 5:20 A.M.
意者請站內寄信給 dinos
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.113.158.15