#navi(雑記2009)
書籍案内から、在庫検索への抽出リンク方法を、コードから書名文字列に変更。
書誌検索への抽出リンクはそのままコードにしている。

在庫切れになった場合、書名検索同等で類本抽出することになる。
書籍案内が独自コード扱いで記されている場合でも、書名検索であれば、再出版品などhitする可能性が上がる。KsearchやSSearchへの連携もこの方がすんなり行ける。
コードで正確に抽出する場合は、書誌検索へのリンクから、在庫検索に行けばよい。

一応、書名中、副題や巻数など附加部分は揺らぎとして切り捨て処理している。
当然、データに類似文字列含む書籍も一括抽出することになるが、実用上これで良いと思う。
書誌検索の方へはビタッとhitさせ、在庫検索の方はボワッとhitさせる。そういう使い分け。
こういう2面的処理は古書Project以外では出来ないことだと思うね。>^_^<

書籍案内もかなり使い易くなってきたと自己満足。
----
もうじき5時。室温13度。
----
快晴。昼風呂。室温16度。
湯冷めせぬよう、一応ダウンのハーフコート。
いつの間にか強張っていた腕の筋肉ほぐすとビリビリくる。
----
複数文字列のand検索を行うLogicを考える。
-1.文字列Ａ・Ｂ・Ｃ・・・Ｎ迄、n個の文字列でand検索するとして、
文字列n個を配列に入れる。配列から順に1個づつ取りだし、
対象データ内にＡがあれば、1をcount
対象データ内にＢがあれば、countに1を加える。
という作業を順にＮ迄行い、count数がnになっていれば、Ａ〜Ｎの文字列が全て対象データ内にあると云うことになる。
--と云う方法で、文字列がいくら増えてもand検索は可能。
別段配列に入れなくても構わないのだが、配列に入れた方が処理が楽。
（orの場合はcount数が1以上であれば該当すると判定）

-2.文字列Ａ・Ｂ・Ｃ・・・Ｎ迄、n個の文字列でand検索するとして、
対象データ内にＡがあれば、次の文字Ｂがあるかどうか調べる。無ければ処理終わり。
次にＢがあれば、その次のＣがあるかどうか調べる。無ければ処理終わり。
処理が最後のＮの検査迄進んで、Ｎがあることを確認できたら、
Ａ〜Ｎの文字列が全て対象データー内にあると判定。

1の方法と2の方法を比較すると、サーバー負担の少ないのは2の方だと思われる。
但しプログラムは冗長になりそうだ。

1の方法と2の方法組み合わせると、
1において、検査回数を別カウントし、検査回数とhit回数が不一致になった場合には処理を終了させるという方法で、コンパクト化が出来そうだ。

まあそういうことなのだが、こういう処理が必要なのかどうか・・・・。
せいぜい3〜4文字列のandに制限しておいた方が良いような気もする。
10文字列のandとか100文字列のandとか、普通しないだろうし、するとすれば悪戯だよなぁ。
----
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS