#navi(雑記2009) 書籍案内から、在庫検索への抽出リンク方法を、コードから書名文字列に変更。 書誌検索への抽出リンクはそのままコードにしている。 在庫切れになった場合、書名検索同等で類本抽出することになる。 書籍案内が独自コード扱いで記されている場合でも、書名検索であれば、再出版品などhitする可能性が上がる。KsearchやSSearchへの連携もこの方がすんなり行ける。 コードで正確に抽出する場合は、書誌検索へのリンクから、在庫検索に行けばよい。 一応、書名中、副題や巻数など附加部分は揺らぎとして切り捨て処理している。 当然、データに類似文字列含む書籍も一括抽出することになるが、実用上これで良いと思う。 書誌検索の方へはビタッとhitさせ、在庫検索の方はボワッとhitさせる。そういう使い分け。 こういう2面的処理は古書Project以外では出来ないことだと思うね。>^_^< 書籍案内もかなり使い易くなってきたと自己満足。 ---- もうじき5時。室温13度。 ---- 快晴。昼風呂。室温16度。 湯冷めせぬよう、一応ダウンのハーフコート。 いつの間にか強張っていた腕の筋肉ほぐすとビリビリくる。 ---- 複数文字列のand検索を行うLogicを考える。 -1.文字列A・B・C・・・N迄、n個の文字列でand検索するとして、 文字列n個を配列に入れる。配列から順に1個づつ取りだし、 対象データ内にAがあれば、1をcount 対象データ内にBがあれば、countに1を加える。 という作業を順にN迄行い、count数がnになっていれば、A〜Nの文字列が全て対象データ内にあると云うことになる。 --と云う方法で、文字列がいくら増えてもand検索は可能。 別段配列に入れなくても構わないのだが、配列に入れた方が処理が楽。 (orの場合はcount数が1以上であれば該当すると判定) -2.文字列A・B・C・・・N迄、n個の文字列でand検索するとして、 対象データ内にAがあれば、次の文字Bがあるかどうか調べる。無ければ処理終わり。 次にBがあれば、その次のCがあるかどうか調べる。無ければ処理終わり。 処理が最後のNの検査迄進んで、Nがあることを確認できたら、 A〜Nの文字列が全て対象データー内にあると判定。 1の方法と2の方法を比較すると、サーバー負担の少ないのは2の方だと思われる。 但しプログラムは冗長になりそうだ。 1の方法と2の方法組み合わせると、 1において、検査回数を別カウントし、検査回数とhit回数が不一致になった場合には処理を終了させるという方法で、コンパクト化が出来そうだ。 まあそういうことなのだが、こういう処理が必要なのかどうか・・・・。 せいぜい3〜4文字列のandに制限しておいた方が良いような気もする。 10文字列のandとか100文字列のandとか、普通しないだろうし、するとすれば悪戯だよなぁ。 ----