[掲示板: 〈過去ログ〉オフ会参加募集・報告 -- 最新メッセージID: 14793 // 時刻: 2024/11/5(03:04)]
上へ | 前のメッセージへ | 次のメッセージへ | ここから後の返答を全表示 | 返答を書き込む | 訂正する | 削除する
お名前: 古川@SSS http://www.seg.co.jp/
投稿日: 2003/9/11(02:32)
------------------------------
古川です。
〉〉1.書評の検索について(必要な項目・増やしてほしい項目・いらない項目等)
〉いらないかなぁの項目
〉 条件検索に不要
〉 備考
〉 (条件検索に不要としても、例えば全文検索でカバーしていれば良い)
〉 (条件検索は、もちょっと項目を減らす)
〉 レベル
〉 YLに統一なら統一する。でも移行措置として、DBにはレベルは
〉 残し、YLの指定でレベルも検索する。
〉 YL6.6が指定されたら。レベル6も含むとか...ちと乱暴かな。
〉 旧レベルも検索するチェックを持つのも良いかも。
〉 語彙レベル なんかレベルがいっぱいなので....
レベルは YL に統一されます。
各社のレベルは、各シリーズごとにもつ 各シリーズのレベル となります。
語彙レベルは、 GRにのみ設定されます。
レベルの検索は YLでの検索のみになります。
ただし、各社のシリーズを選択した場合、その後、各シリーズのレベルや
語彙レベルで絞り込みをできるようにします。
〉〉2.書評登録時について(どうしたら登録しやすくなるか)
〉・レベルの削減(もしくは統合) YL,レベル、語彙レベル
〉・出来うる限りプルダウン選択
〉 出版社とか。プルダウン以外も書けないといけませんが...
〉・登録時に書籍の調べモノもするので、登録画面内にアマゾンへのリンクを張る。しかも、登録画面でISBNを入れておいたら、そのISBNで検索。
これは 便利だけど難しい?
〉・総単語数計算をもう少し使いやすくする。
〉 「計算」ボタンがあって、必要項目をいれて押せば、語数が判る。
これは重要なことですが、必要項目もDBの表の中にもっていないと
間違いを発見するのが難しいです。
〉・途中入力で中断しても良いようにする。
〉 新書籍の場合は、ISBNで排他する。
今でもそうなっています。
〉 自分のIDでの中断、再開。何日間か入力中断しているものは管理者が判る。
作業中:作業者:完了予定日 なんていうのをいれる領域があるといいですね。
〉・自分の入力したものがログイン時に判る。
ちょっとイメージを教えてください。
〉 マイページの一部?
〉・他人の書評のコピーができる。(入力の手間を省く)
ウインドウを2つあけて、cut & Paste ができればいいかと思います。
〉 他の書評の参考複写
〉・評価のある程度の定型化
〉 泣いた、笑った、感動した等々....(これも少しでも入力しやすく)
いいですね。
〉〉3.ヘルプについて(どういった形のヘルプがほしいか)
〉・・がやりたい時にはこう使うといった、運用面から見たヘルプです。
〉ヘルプを見ながら操作が考えられるので、形式的には、HTMLで、別ウィン
〉ドウが開けば良いと思います。
〉検索、登録のどういった運用・使い方が考えられるかは、練らないといけませんね。
〉使い方は、徐々にたまるものなので、書評委員が増やせるのは良い案と思います。
〉〉4.その他なんでもご意見
〉・書評の全文検索機能
〉 別途、全文検索をする対象項目は絞る必要があると思います。
〉 イメージとしては、google,NAMAZUなんですが、RDBMSを使うでしょうから、
〉 ちと辛い かもしれませんね。...できてもパフォーマンスが落ちるかもしれ
〉 ませんね。
〉 でも、今時は、googleで全文検索のような検索をするのに慣れているので
〉 あると、概念的にはなじみやすいと思います。
〉・appleさんに援護射撃を受けましたが、シャドウイングの音声素材閲覧・検索
〉 の機能が欲しいです。
本とむすびついている音声素材 と 単独の音声素材 があり、
前者には本とのむつび付きが必要。 それをどう実現するか?
〉・パフォーマンス調整(必要があればパフォーマンスを上げるためのメモリ
〉 等増設含む)にもある程度力を入れる
〉 Oracleで言うと、適切にインデックスを張っておく等です。
〉 like検索に気を付ける等、SQLの表現...(かなり内々の話になりますが...)
〉・編集ログ 書評登録、変更、削除については、何を誰が行ったか判る手段
〉 を確保する。
〉 編集ログテーブルを作るのも良いかもしれません。
〉 持つ情報は、半年分くらいでしょうか。
これをだれか見ることがあるかなあ?
でも、あれば便利ですが?
ひこさん、具体的にどんな場合を想定されていますか?
〉・デイリーバックアップ(もしくは、12時間か6時間に1回)と
〉 リカバリ手順の作り込み(DB破損等に備えて)
〉 さらに、ウィークリーもしくはマンスリーバックアップで、外部記憶装置
〉 に情報を持って行く。(機器故障に備えて)
〉 不測の事態時に、運用する方が最後のバックアップの状態までは、
〉 すぐに戻れる。
〉 これと、編集ログを組み合わせれば、何かが起こった時の直前の状態
〉 に戻れる。
コストとメンテナンスの手間とのバランスですね。
もし、簡単にできる、簡易に作れるなら 好ましいし、
費用がかなりかるなら そこまでする必然性はない思います。
〉・マスタテーブルメンテナンス
〉 シリーズ名等のプルダウンのマスタテーブルは、後で書評委員の人等が
〉 変更可能なような機能を持つ。
〉 ユーザインターフェースを持たなくても良いので、手段を持つ感じ。
そうですね。
〉・条件検索時のISBN指定で、「−」ハイフンを含んでいても検索
〉 →アマゾンからコピペでもってきてそのまま検索可能とする。
アマゾンも ハイフンは 無しじゃあないですか?
〉・現画面の書籍検索に、ISBNを含める。
〉 →ISBNで引くことが私は、多いです。
賛成
〉これほどの書評がデータとしてあるので、機能も必要ですが、どちらかと言う
〉と、安定した動作と情報を守るためのことをちょっと考えてみました。
〉バックアップ等今実施しているコトも多いかもしれませんね。
〉まとまりなく、つらつらと書いてみました。
〉では。
ありがとう!
▲返答元
▼返答