我目前的項目是一個帶布爾檢索功能的高級標籤數據庫。記錄被查詢與(在音樂數據庫例如)布爾表達式像這樣:爲緩存原因規範化布爾表達式。有沒有比真值表更有效的方法?
funky-music and not (live or cover)
應該得到所有時髦的音樂在音樂數據庫,但不居住或歌曲的翻唱版本。
當涉及到緩存時,問題是存在相同但查詢結構不同的查詢。例如,將德,摩根的規則,上面的查詢可以這樣寫:
funky-music and not live and not cover
緩存將通過散列查詢字符串,例如執行時會產生完全相同的記錄,但事業突破的緩存。
因此,我的第一個意圖是創建一個查詢的真值表,然後可以用作緩存鍵作爲等價表達式形成相同的真值表。不幸的是,這是不可行的,因爲真值表隨着輸入數量(標籤)呈指數增長,我不想限制一個查詢中使用的標籤數量。
另一種方法是遍歷應用由布爾代數定義的規則的語法樹,以形成(最小)規範化表示,這似乎也很棘手。
因此,總體問題是:是否有一種可行的方法來實現等效查詢的識別,而不需要circuit minimization或真值表(編輯:或任何其他算法是NP-hard)?
ne plus ultra會識別已經緩存的子查詢,但這不是主要目標。
使用按位鍵 - 例如。設置位0如果時髦|位6 0 =住/ 1 =工作室|位8 rap |位9彈出 然後您使用按位操作來確定查詢 上的密鑰表示是否有意義? – Dan 2011-05-01 14:50:49
這是移動設備API中的一種常見模式 - createScreen(long style_element),其中long style_element是所述按位操作的最終結果,並且爲所述Screen對象指定了無盡的(真正的lol)樣式元素 – Dan 2011-05-01 15:31:09
這將是一種內存有效的方式將信息存儲在數據庫中。但這是一個完全不同的話題。 – user733321 2011-05-01 17:38:46