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

ひこです。

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

〉〉・登録時に書籍の調べモノもするので、登録画面内にアマゾンへのリンクを張る。しかも、登録画面で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さんに援護射撃を受けましたが、シャドウイングの音声素材閲覧・検索
〉〉　の機能が欲しいです。

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

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

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

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

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

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

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

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