Re: 新書評検索システムへの意見募集

ひこです。優香さん、こんばんわ。

〉(1)書評検索はこれまでどおり誰でも利用できる
〉(2)各ブッククラブは保有図書の在庫登録を行い、利用者は書評検索時にブッククラブの所有を確認できる
〉(3)ユーザー登録をした会員はマイページに読書履歴を持つことができる
〉(4)ヘルプに関しては書評委員が登録・編集できるようにする

〉今回、特に意見を募集したいのは

〉１．書評の検索について（必要な項目・増やしてほしい項目・いらない項目等）
いらないかなぁの項目
　条件検索に不要
　　　備考
　　　（条件検索に不要としても、例えば全文検索でカバーしていれば良い）
　　　（条件検索は、もちょっと項目を減らす）
　　　レベル
　　　　ＹＬに統一なら統一する。でも移行措置として、ＤＢにはレベルは
　　　　残し、ＹＬの指定でレベルも検索する。
　　　　　ＹＬ６．６が指定されたら。レベル６も含むとか...ちと乱暴かな。
　　　　　旧レベルも検索するチェックを持つのも良いかも。
　　　語彙レベル　なんかレベルがいっぱいなので....

　項目そのものが不要　
　　　特に削る項目は無し....但し、レベルを統一するのであれば「レベル」
　　　という項目は無くなるのかもしれませんね。

〉２．書評登録時について（どうしたら登録しやすくなるか）
・レベルの削減（もしくは統合）　ＹＬ，レベル、語彙レベル
・出来うる限りプルダウン選択
　　出版社とか。プルダウン以外も書けないといけませんが...
・登録時に書籍の調べモノもするので、登録画面内にアマゾンへのリンクを張る。しかも、登録画面でISBNを入れておいたら、そのISBNで検索。
・総単語数計算をもう少し使いやすくする。
　「計算」ボタンがあって、必要項目をいれて押せば、語数が判る。
・途中入力で中断しても良いようにする。
　新書籍の場合は、ISBNで排他する。
　自分のＩＤでの中断、再開。何日間か入力中断しているものは管理者が判る。
・自分の入力したものがログイン時に判る。
　マイページの一部？
・他人の書評のコピーができる。（入力の手間を省く）
　　他の書評の参考複写
・評価のある程度の定型化
　泣いた、笑った、感動した等々....（これも少しでも入力しやすく）

〉３．ヘルプについて（どういった形のヘルプがほしいか）
・・がやりたい時にはこう使うといった、運用面から見たヘルプです。
ヘルプを見ながら操作が考えられるので、形式的には、ＨＴＭＬで、別ウィン
ドウが開けば良いと思います。
検索、登録のどういった運用・使い方が考えられるかは、練らないといけませんね。
使い方は、徐々にたまるものなので、書評委員が増やせるのは良い案と思います。

〉４．その他なんでもご意見

・書評の全文検索機能
　別途、全文検索をする対象項目は絞る必要があると思います。
　イメージとしては、google,NAMAZUなんですが、RDBMSを使うでしょうから、
　ちと辛い　かもしれませんね。...できてもパフォーマンスが落ちるかもしれ
　ませんね。
　でも、今時は、googleで全文検索のような検索をするのに慣れているので
　あると、概念的にはなじみやすいと思います。

・appleさんに援護射撃を受けましたが、シャドウイングの音声素材閲覧・検索
　の機能が欲しいです。

・パフォーマンス調整（必要があればパフォーマンスを上げるためのメモリ
　等増設含む）にもある程度力を入れる
　Oracleで言うと、適切にインデックスを張っておく等です。
　like検索に気を付ける等、SQLの表現...（かなり内々の話になりますが...）

・編集ログ　書評登録、変更、削除については、何を誰が行ったか判る手段
　を確保する。
　編集ログテーブルを作るのも良いかもしれません。
　持つ情報は、半年分くらいでしょうか。

・デイリーバックアップ（もしくは、１２時間か６時間に１回）と
　リカバリ手順の作り込み（ＤＢ破損等に備えて）
　さらに、ウィークリーもしくはマンスリーバックアップで、外部記憶装置
　に情報を持って行く。（機器故障に備えて）
　　不測の事態時に、運用する方が最後のバックアップの状態までは、
　　すぐに戻れる。
　　これと、編集ログを組み合わせれば、何かが起こった時の直前の状態
　　に戻れる。

・マスタテーブルメンテナンス
　シリーズ名等のプルダウンのマスタテーブルは、後で書評委員の人等が
　変更可能なような機能を持つ。
　ユーザインターフェースを持たなくても良いので、手段を持つ感じ。

・条件検索時のＩＳＢＮ指定で、「−」ハイフンを含んでいても検索
　→アマゾンからコピペでもってきてそのまま検索可能とする。

・現画面の書籍検索に、ＩＳＢＮを含める。
　→ＩＳＢＮで引くことが私は、多いです。

これほどの書評がデータとしてあるので、機能も必要ですが、どちらかと言う
と、安定した動作と情報を守るためのことをちょっと考えてみました。
バックアップ等今実施しているコトも多いかもしれませんね。

まとまりなく、つらつらと書いてみました。
では。

古川です。

〉〉１．書評の検索について（必要な項目・増やしてほしい項目・いらない項目等）
〉いらないかなぁの項目
〉　条件検索に不要
〉　　　備考
〉　　　（条件検索に不要としても、例えば全文検索でカバーしていれば良い）
〉　　　（条件検索は、もちょっと項目を減らす）
〉　　　レベル
〉　　　　ＹＬに統一なら統一する。でも移行措置として、ＤＢにはレベルは
〉　　　　残し、ＹＬの指定でレベルも検索する。
〉　　　　　ＹＬ６．６が指定されたら。レベル６も含むとか...ちと乱暴かな。
〉　　　　　旧レベルも検索するチェックを持つのも良いかも。
〉　　　語彙レベル　なんかレベルがいっぱいなので....

レベルは　ＹＬ　に統一されます。
各社のレベルは、各シリーズごとにもつ　各シリーズのレベル　となります。
語彙レベルは、　ＧＲにのみ設定されます。

レベルの検索は　ＹＬでの検索のみになります。
ただし、各社のシリーズを選択した場合、その後、各シリーズのレベルや
語彙レベルで絞り込みをできるようにします。

〉〉２．書評登録時について（どうしたら登録しやすくなるか）
〉・レベルの削減（もしくは統合）　ＹＬ，レベル、語彙レベル
〉・出来うる限りプルダウン選択
〉　　出版社とか。プルダウン以外も書けないといけませんが...

〉・登録時に書籍の調べモノもするので、登録画面内にアマゾンへのリンクを張る。しかも、登録画面でISBNを入れておいたら、そのISBNで検索。

これは　便利だけど難しい？

〉・総単語数計算をもう少し使いやすくする。
〉　「計算」ボタンがあって、必要項目をいれて押せば、語数が判る。

これは重要なことですが、必要項目もＤＢの表の中にもっていないと
間違いを発見するのが難しいです。

〉・途中入力で中断しても良いようにする。

〉　新書籍の場合は、ISBNで排他する。

今でもそうなっています。

〉　自分のＩＤでの中断、再開。何日間か入力中断しているものは管理者が判る。

作業中：作業者：完了予定日　なんていうのをいれる領域があるといいですね。

〉・自分の入力したものがログイン時に判る。

ちょっとイメージを教えてください。

〉　マイページの一部？
〉・他人の書評のコピーができる。（入力の手間を省く）

ウインドウを２つあけて、cut & Paste ができればいいかと思います。

〉　　他の書評の参考複写
〉・評価のある程度の定型化

〉　泣いた、笑った、感動した等々....（これも少しでも入力しやすく）

いいですね。

〉〉３．ヘルプについて（どういった形のヘルプがほしいか）
〉・・がやりたい時にはこう使うといった、運用面から見たヘルプです。
〉ヘルプを見ながら操作が考えられるので、形式的には、ＨＴＭＬで、別ウィン
〉ドウが開けば良いと思います。

〉検索、登録のどういった運用・使い方が考えられるかは、練らないといけませんね。
〉使い方は、徐々にたまるものなので、書評委員が増やせるのは良い案と思います。

〉〉４．その他なんでもご意見

〉・書評の全文検索機能
〉　別途、全文検索をする対象項目は絞る必要があると思います。
〉　イメージとしては、google,NAMAZUなんですが、RDBMSを使うでしょうから、
〉　ちと辛い　かもしれませんね。...できてもパフォーマンスが落ちるかもしれ
〉　ませんね。
〉　でも、今時は、googleで全文検索のような検索をするのに慣れているので
〉　あると、概念的にはなじみやすいと思います。

〉・appleさんに援護射撃を受けましたが、シャドウイングの音声素材閲覧・検索
〉　の機能が欲しいです。

本とむすびついている音声素材　と　単独の音声素材　があり、
前者には本とのむつび付きが必要。　それをどう実現するか？

〉・パフォーマンス調整（必要があればパフォーマンスを上げるためのメモリ
〉　等増設含む）にもある程度力を入れる

〉　Oracleで言うと、適切にインデックスを張っておく等です。

〉　like検索に気を付ける等、SQLの表現...（かなり内々の話になりますが...）

〉・編集ログ　書評登録、変更、削除については、何を誰が行ったか判る手段
〉　を確保する。
〉　編集ログテーブルを作るのも良いかもしれません。
〉　持つ情報は、半年分くらいでしょうか。

これをだれか見ることがあるかなあ？
でも、あれば便利ですが？
ひこさん、具体的にどんな場合を想定されていますか？

〉・デイリーバックアップ（もしくは、１２時間か６時間に１回）と
〉　リカバリ手順の作り込み（ＤＢ破損等に備えて）
〉　さらに、ウィークリーもしくはマンスリーバックアップで、外部記憶装置
〉　に情報を持って行く。（機器故障に備えて）
〉　　不測の事態時に、運用する方が最後のバックアップの状態までは、
〉　　すぐに戻れる。
〉　　これと、編集ログを組み合わせれば、何かが起こった時の直前の状態
〉　　に戻れる。

コストとメンテナンスの手間とのバランスですね。
もし、簡単にできる、簡易に作れるなら　好ましいし、
費用がかなりかるなら　そこまでする必然性はない思います。

〉・マスタテーブルメンテナンス
〉　シリーズ名等のプルダウンのマスタテーブルは、後で書評委員の人等が
〉　変更可能なような機能を持つ。
〉　ユーザインターフェースを持たなくても良いので、手段を持つ感じ。

そうですね。

〉・条件検索時のＩＳＢＮ指定で、「−」ハイフンを含んでいても検索
〉　→アマゾンからコピペでもってきてそのまま検索可能とする。

アマゾンも　ハイフンは　無しじゃあないですか？

〉・現画面の書籍検索に、ＩＳＢＮを含める。
〉　→ＩＳＢＮで引くことが私は、多いです。

賛成

〉これほどの書評がデータとしてあるので、機能も必要ですが、どちらかと言う
〉と、安定した動作と情報を守るためのことをちょっと考えてみました。
〉バックアップ等今実施しているコトも多いかもしれませんね。

〉まとまりなく、つらつらと書いてみました。
〉では。

ありがとう！

古川さん、ひこさん、おはようございます。

〉レベルは　ＹＬ　に統一されます。
〉各社のレベルは、各シリーズごとにもつ　各シリーズのレベル　となります。
〉語彙レベルは、　ＧＲにのみ設定されます。

YLに統一されると、書評に慣れた人でないと、新規書評を上げにくくなる、
という気がしています。
別に、書評委員になるために、YL診断力テストにパスした人でないと・・・
とか言うわけではないので。

〉〉・途中入力で中断しても良いようにする。
〉〉　新書籍の場合は、ISBNで排他する。
〉今でもそうなっています。

入力する前に排他してほしいの意味ではないでしょうか？

〉〉・パフォーマンス調整（必要があればパフォーマンスを上げるためのメモリ
〉〉　等増設含む）にもある程度力を入れる
〉〉　Oracleで言うと、適切にインデックスを張っておく等です。
〉〉　like検索に気を付ける等、SQLの表現...（かなり内々の話になりますが...）

これは、当然やってくれるものと思い、書きませんでした。

〉〉・編集ログ　書評登録、変更、削除については、何を誰が行ったか判る手段
〉〉　を確保する。
〉〉　編集ログテーブルを作るのも良いかもしれません。
〉〉　持つ情報は、半年分くらいでしょうか。
〉これをだれか見ることがあるかなあ？
〉でも、あれば便利ですが？
〉ひこさん、具体的にどんな場合を想定されていますか？

少なくとも、SSS事務局のかたが、チェックされるのに必要かも。
例えば間違えてISBNを入力してしまった場合の上書き対策とか？

〉〉・デイリーバックアップ（もしくは、１２時間か６時間に１回）と
〉〉　リカバリ手順の作り込み（ＤＢ破損等に備えて）
〉〉　さらに、ウィークリーもしくはマンスリーバックアップで、外部記憶装置
〉〉　に情報を持って行く。（機器故障に備えて）
〉〉　　不測の事態時に、運用する方が最後のバックアップの状態までは、
〉〉　　すぐに戻れる。
〉〉　　これと、編集ログを組み合わせれば、何かが起こった時の直前の状態
〉〉　　に戻れる。
〉コストとメンテナンスの手間とのバランスですね。
〉もし、簡単にできる、簡易に作れるなら　好ましいし、
〉費用がかなりかるなら　そこまでする必然性はない思います。

私は、必須だと思います。
というか、あると思っていたので、あえて書きませんでした。
フルバックアップと差分バックアップを適切に組み合わせれば、
良いと思います。

ひこです。

〉〉〉２．書評登録時について（どうしたら登録しやすくなるか）
〉〉・レベルの削減（もしくは統合）　ＹＬ，レベル、語彙レベル
〉〉・出来うる限りプルダウン選択
〉〉　　出版社とか。プルダウン以外も書けないといけませんが...

〉〉・登録時に書籍の調べモノもするので、登録画面内にアマゾンへのリンクを張る。しかも、登録画面でISBNを入れておいたら、そのISBNで検索。

〉これは　便利だけど難しい？
そんなに難しくないと思っています。
JavaScriptで、現在入力中の値(ISBNの値）を持って、
http://www.amazon.co.jp/exec/obidos/ASIN/（ここにISBNの値）/sss-22/250-5142344-5513848
のようなURLを構成して、新ウィンドウを生成すれば良いと思っています。
できないかなぁ。
ただ、このまま購入に走ると５％にならないですけどね...

〉〉・総単語数計算をもう少し使いやすくする。
〉〉　「計算」ボタンがあって、必要項目をいれて押せば、語数が判る。

〉これは重要なことですが、必要項目もＤＢの表の中にもっていないと
〉間違いを発見するのが難しいです。
総語数以外は、DBの中に持つ必要は無いです。
語数計算という行為を手伝ってあげるイメージです。
何回も計算し直して良いように、「計算」ボタンを付けます。

〉〉・途中入力で中断しても良いようにする。

〉〉　新書籍の場合は、ISBNで排他する。
〉今でもそうなっています。
すいません。現仕様を把握していませんでした。
登録時でのチェックで十分と思います。

〉〉　自分のＩＤでの中断、再開。何日間か入力中断しているものは管理者が判る。

〉作業中：作業者：完了予定日　なんていうのをいれる領域があるといいですね。

〉〉・自分の入力したものがログイン時に判る。
〉ちょっとイメージを教えてください。
マイページがあると仮定して、ログイン時に、自分の編集した書評が
ずらりとWEB上に一覧で出ている。
実は、作業中のものの一覧が出れば、作業再開がしやすいと考えて、
自分が入力した書評が出ると、それを使って何か作業するかなと思った
までです。で、作業中のもの一覧以外は、あまり使いようが無いですね。
作業済みの自分の書評一覧は取り下げます。

〉〉　マイページの一部？
〉〉・他人の書評のコピーができる。（入力の手間を省く）
〉ウインドウを２つあけて、cut & Paste ができればいいかと思います。
そうですね。作る必要はないかも。

〉〉・appleさんに援護射撃を受けましたが、シャドウイングの音声素材閲覧・検索
〉〉　の機能が欲しいです。

〉本とむすびついている音声素材　と　単独の音声素材　があり、
〉前者には本とのむつび付きが必要。　それをどう実現するか？
テーブル間にリンクを張る方法と、同一ＤＢ（テーブル）で管理する方法が
あります。テーブル間にリンクを張る方法は、業務システム等で良く行う
方法なのですが、難易度が高いので、同一ＤＢ（テーブル）をうまく使う
のが良いと思います。
複数テーブルにする場合は、リンクも緩いリンクにする方法もあります。
で、もしそうするならば、どんな項目を増やせば良いかですよね。
同一テーブルにする場合は、本向けのカラムと、音声素材向けのカラムが混在
するようになります。
現在書評は、３７００冊分（何レコードだろ...）
今までずいぶん入れた感じもあるので、今後は急激には増えないとして
シャドウイング素材も込みで、３年後３倍としたら１万ちょっとですね。
う〜ん。１万かぁ。同一テーブルにするのをちょっとためらうかもしれない...
まぁ、参考までのお話でした。
でも、機能は欲しいですね。

〉〉・パフォーマンス調整（必要があればパフォーマンスを上げるためのメモリ
〉〉　等増設含む）にもある程度力を入れる
これは、意識してある程度やっておいた方が良いですよ。
使い始めて、機能はなんとか実現しても、パフォーマンスが出なくなることは
ままあります。私も泣いたことがあります。
データ量（現状、数年後見込み）、リンク関係、サーバＣＰＵスペック、
メモリ、ハードディスクの配置状況、プログラムの複雑さ、インデクス、
ＤＢのキャッシュ設定、使用するソフトとの階層関係　等チェックポイントは
あるので、コストパフォーマンスを考えて利きそうなところに目配りをあらか
じめしておくのが幸せだと思います。

〉〉・編集ログ　書評登録、変更、削除については、何を誰が行ったか判る手段
〉〉　を確保する。
〉〉　編集ログテーブルを作るのも良いかもしれません。
〉〉　持つ情報は、半年分くらいでしょうか。

〉これをだれか見ることがあるかなあ？
〉でも、あれば便利ですが？
〉ひこさん、具体的にどんな場合を想定されていますか？
場面：データ誤入力、ＰＧ障害でのデータ破損時の復旧の元ネタ
　　　障害追跡の元ネタ
使用者：システム管理者、プログラム開発者
効果・目的：
　うまく書評が登録、更新、削除されているときは、効果、使い道無し。
　一旦障害が出て、書評システムが使えなくなったとき、
　　データの復旧が必要→データ復旧の手がかりとなり、復旧が早い
　　ＰＧ障害が見込まれるとき→ＰＧ障害ヶ所が早期に見つかり、復旧が早い
　こういった手だてが無い時（ちょっと極端な表現をしますね）
　　最悪、データが復旧しない、中途半端な復旧に終わる、バックアップ時
　　のデータまでしか復旧しない。
　　ＰＧ障害の原因がどうしても特定しづらく、サービス（書評システム）
　　の中止が長引く
どのようなログをとるか、費用がどの位かかるかは、ログの取り方にもよります。
これも、費用対効果のバランスですので、やらないとするならば、手だてが無い
時の事態が起こるかもしれないのを頭に入れておく必要があります。
えーと、多少なりともログがとれる工夫をしたらどうでしょうかといった
コメントになります。

〉〉・デイリーバックアップ（もしくは、１２時間か６時間に１回）と
〉〉　リカバリ手順の作り込み（ＤＢ破損等に備えて）
〉〉　さらに、ウィークリーもしくはマンスリーバックアップで、外部記憶装置
〉〉　に情報を持って行く。（機器故障に備えて）
〉〉　　不測の事態時に、運用する方が最後のバックアップの状態までは、
〉〉　　すぐに戻れる。
〉〉　　これと、編集ログを組み合わせれば、何かが起こった時の直前の状態
〉〉　　に戻れる。

〉コストとメンテナンスの手間とのバランスですね。
〉もし、簡単にできる、簡易に作れるなら　好ましいし、
〉費用がかなりかるなら　そこまでする必然性はない思います。
その通りですが、最悪データが一気になくなる怖さもあるので、何らかのバッ
クアップ手段を持っておいた方が良いと思います。
専門的になりますが、ＤＢが稼働するサーバにクーロンで、差分バックアップ
とかフルバックアップのバッチを配置するだけでも違います。
別の媒体にまで定期的に出力するとさらに安全ですね。
ＰＧ上の手間と言うわけではなく、手順の作り込みの手間です。
すごいＰＧの作り込みをする訳では無いので、何らかの手段を入れておいた方
が良いと思います。実は、ＤＢだけでなく、掲示板のデータもうまくバックアップ
をいっしょに取れたら良いですね。

〉〉・条件検索時のＩＳＢＮ指定で、「−」ハイフンを含んでいても検索
〉〉　→アマゾンからコピペでもってきてそのまま検索可能とする。
〉アマゾンも　ハイフンは　無しじゃあないですか？
あれ、すいません。そうでしたね。
えーと、本を見ながらＩＳＢＮを入れる人がいて、-をもし入れた時は、
-を自動的に抜くといった、ちょっとしたＰＧのことを言いました。

〉〉これほどの書評がデータとしてあるので、機能も必要ですが、どちらかと言う
〉〉と、安定した動作と情報を守るためのことをちょっと考えてみました。
〉〉バックアップ等今実施しているコトも多いかもしれませんね。
やっぱり、データを守ることも考えに入れて下さいね。
機能と比較すると、どうしても地味ですが、重要なところですので....