小林です。

> その一部公開できないデータが混在したデータを、どのような構造のテーブルに
> 格納しようとしているのかわからないと、やりたいコトがクエリだけで実現可能
> かどうかはわからないですよ;)
すみません。。。テーブル構造は今のところ
本文を保存しておくtext型のカラムと
権限レベルを保存しておくint型のカラム
あと保存した日時などを保存しておくカラム（今回の件にはあまり関係ない）
しか考えてませんでした。
つまり記事内容がそのまんま入っているわけです。
ただまだいくらでも構造を変えられるので
よりよい構造にできるならその方向性で検討していくつもりです。


> 少なくとも通常のDB設計の考え方からすれば、異なる性質のデータは異なるカラ
> ムに格納するのが基本ですから、公開レベルの異なるテキストを同じカラムに格
> 納している時点でSQLで対処すべき範囲から外れるのではないかとわたしは思い
> ます。
なるほど、理解しました。
たしかに調べる対象にないものを調べにいくという時点で微妙なのですね。
あとからマスクする部分に引っかかるかで非公開にするかは私も考えたのですが
それだとヒットする記事数のcountができないので微妙かなという感じです。
やはり別カラムに保存する方向性で考えてみたいと思います。


----- Original Message ----- 
From: "Ayumu, Aizawa" <ayumu.aizawa@g...>
To: <rails@r...>
Sent: Wednesday, August 30, 2006 11:39 PM
Subject: [rails:1582] Re: 検索機能について


> あいざわです。
>
>> いま行おうとしているのは何か文書をwiki上で公開しようとしたときに、
>> その「一部」に公開不可能なものがあったとき（主に個人情報）、
>> それだけを閲覧不可能にしよう、という機能なのです。
>> つまり結構な頻度でhiddenにする可能性があります。
>> （これは実際に使用する側にコンタクトを取ってみないと詳しくはわからないので 
>> 
> すが）
>
> その一部公開できないデータが混在したデータを、どのような構造のテーブルに
> 格納しようとしているのかわからないと、やりたいコトがクエリだけで実現可能
> かどうかはわからないですよ;)
>
> 少なくとも通常のDB設計の考え方からすれば、異なる性質のデータは異なるカラ
> ムに格納するのが基本ですから、公開レベルの異なるテキストを同じカラムに格
> 納している時点でSQLで対処すべき範囲から外れるのではないかとわたしは思い
> ます。
> 非公開部分を'*'で置換するのであれば、データを取得してきた後に正規表現でマ
> スクすればいいとおもいますが、非公開部分が検索にヒットしない（ように見せかけ 
> 
> る）
> ための手段はなにか考える必要がありそうです。
>
> たとえば
> 　普通に検索する（SQL）
> 　if　ユーザからのリクエストの場合
> 　　1.　データのマスキングをおこなう（正規表現で置換）
> 　　2.　マスキング後のデータが当初の検索条件にひっかかるか判断する（正規表
> 現）
> 　　　2-1.　上記2.の処理で「マッチした」場合、
> 　　　　当該データは、非公開部分を除く個所で検索条件にヒットしたデータ
> 　　　　であるとわかる
> 　　　　⇒　マスク後のデータをユーザーに公開する
> 　　　2-2.　上記2.の処理で「マッチしなかった」場合、
> 　　　　当該データは、非公開部分で検索条件にヒットしたデータであるとわかる
> 　　　　⇒　ユーザーに公開しない
>
> のような処理です。
>
>
> --
> ML: rails@r...
> 使い方: http://QuickML.com/ 


--
ML: rails@r...
使い方: http://QuickML.com/