明細フォームの作りは、どの方法が最適でしょうか?(配列、テキスト、ワークテーブル)

[上に] [前に] [次に]
じゅん 1999/11/19(金) 09:35:42
現在、社内のホームページ&日報入力を作成中です。

日報入力は、複数明細入力できるようにとの要望がありました。
・ヘッダ部分に入力日を入力します。
・明細部分には、開始・終了時間、作業内容などを入力します。
・明細の数は、登録する度に増えていきます。
・明細の修正、削除も可能です。
・明細を削除した場合、削除部分を詰めて表示します。

画面は、以下のイメージです。
----ヘッダ部分---------------------------
部署名 担当者名 日報入力日
営業部 営業太郎 1999/11/10
----------------------------------------

---明細部分------------------------------
a@開始時間 終了時間 作業内容
01  08:30    13:00     開発作業
02  13:30    15:20     打合せ
-----------------------------------------

この仕様を実現しようとすると、明細の情報を、なにかしらに一時保存
する必要があると思いました。

そこで、テキストファイル、配列変数、データーベースのワークテーブルが使えそうだなと考えたのですが、一般的に、Webの場合、どの方法が最適なのでしょうか?

テキストファイル、配列変数は、クライアント側の処理なので、サーバーに負荷はかからないと思うのですが、データの追加、更新、削除の処理が大変そうです。

データベースのワークテーブルだと、データの追加、更新、削除はSQL文で制御できますが、サーバーの負荷が心配です。

ちなみに、日報入力する社員は、約100人です。
LAN−WAN−LANで使用します。
たしか、フレームリレーだったかな?

現状を考えると、テキストファイルか、配列が良いのかなと思っているのですが....

よろしくお願いします。

ぎん 1999/11/19(金) 12:54:28
あまり詳しくなのですが、(^^;

> 明細の情報を、なにかしらに一時保存
一時保存とありますが、あるPCで打ち込んだ日報は、
他のPCでも、見れないといけないんですよね?

> テキストファイル、配列変数は、クライアント側の処理
クライアント側ですか?ちょっとよくわかりませんが。。。

> データの追加、更新、削除はSQL文で制御できますが、サーバーの負荷心配です。
サーバー等の性能によりますが、
このくらいであれば、サーバーの負荷はほとんどないと思います。
それより心配なのは、WANの接続方法です。
接続しっぱなしの専用線INS64などであれば、いいと思うけど、
まさか、ダイヤルアップではないですよね。(^^;)

そのあたりを把握されていて、
もし、CGIでの登録/更新データを、テキストorデータベース
でお悩みなら、
そのデータの「今後の扱い」で扱いやすい方でいいのだと
思います。

レスポンスなどは、簡単なものをつくってテストしてみた方が
いいですよ。

匿名希望 1999/11/19(金) 12:57:15
ひとつの戯言だと思って聞いて下さい!

100人で毎日だと結構データ量がありますのでデータベース(DB)がベターでしょう。
だた、DBだとお金もかかるし、インストール、チューンナップが大変です。
また、CGIにしてもDBとのインターフェイスが結構難しかったりします。

そこで、次はテキストになりますが、データ形式はタブのCSV形式をお勧めします。
デリミタが「,」だとデータ中に入る可能性がありるねで...。
また、CSVにするとPCにダウンロードした時Excel等でデータ加工がしやすいです。

あと、配列変数はCGIが終了すると消滅します!!

じゅん 1999/11/19(金) 13:51:05
ぎんさん、匿名希望さん、アドバイスありがとうございます。

>一時保存とありますが、あるPCで打ち込んだ日報は、
>他のPCでも、見れないといけないんですよね?
>クライアント側ですか?ちょっとよくわかりませんが。。。

>100人で毎日だと結構データ量がありますのでデータベース(DB)
>がベターでしょう。

私の説明不足でした。

最終的には、サーバーのデータベース(Oracle)に更新します。
画面の更新ボタンを押下した時点で、一時保存(クライアントに
書き込んだ、テキストファイル又は配列変数か、サーバーワーク
テーブル)したデータを、サーバーの本テーブルに更新しようと
考えていました。

今回、利用者が100人近くいますので、明細の追加、削除の度に、サーバーにアクセスするのは、どうかなという理由もありました。
まあ、同時に100人が使用することは無いと思いますが。。

>接続しっぱなしの専用線INS64などであれば、いいと思うけど、
>まさか、ダイヤルアップではないですよね。(^^;)

あの...それが、ダイヤルアップもあるんです。
とりあえず、専用線にかえてくださいと、依頼中です。
でも、現状のままになりそうな雰囲気です。(^^;)

>レスポンスなどは、簡単なものをつくってテストしてみた方が
>いいですよ。
そうですよね。たしかに、レスポンステストはしなければ...

>そこで、次はテキストになりますが、データ形式はタブのCSV形式を
>お勧めします。
>デリミタが「,」だとデータ中に入る可能性がありるねで...。
>また、CSVにするとPCにダウンロードした時Excel等でデータ加工が
>しやすいです。

なるほど、参考にさせて頂きます。

と言うような現状です。
再度、お聞きして申し訳有りませんが、お知恵を拝借させてください。

wosamu 1999/11/19(金) 14:06:11
まだまったく作られていないのでしょうか?
もし日報をブラウザ上から入力してそれをほかから見る必要があるのあるならば
サーバ上に何らかの形で保存しておく必要があるでしょう。
>そこで、テキストファイル、配列変数、データーベースのワークテーブルが使えそうだなと考えたのですが、一般的に、Webの場合、どの方法が最適なのでしょうか?
まずこれ以前にどのような環境で開発されるか考えられたほうがよいと思いますけれど。

ふじ 1999/11/19(金) 14:08:43
基本的に、CGIではクライアント側にファイルを作ることは出来ません。

クッキーになら書き込めますが、書き込める量に制限があります。
また、クッキーに書き込んだところでいつかは(ブラウザ側のアクションとして)
サーバに繋がないと、サーバにデータを送れないので、
(今回の場合)使ってもそれほど意味はないかと思います。

1.サーバ側にテキストファイルで保存して、ある程度まとまったら
  それを DB に投入。

2.データの入力ごとに DB に接続してデータ投入。

の、どちらかでしょう。
まず 2. のやり方でレスポンスがどの程度なのかを実験して、
それで速度、負荷的な問題が大きければ 1. をやってみる、
というのが良いかと思います。
#データの保護、一元性の確保等については DB に任せた方が
#良いでしょうから。

ちゃいパパ 1999/11/19(金) 14:51:30
私もふじさんと同感です。

データ量は少ない時はテキストで、ある時点からoracleの方がアクセスが速くなるみたいです。
(正確なとこはわかりません)
また、oracleは時々無応答になりますので、シビアな処理はfork()でSQL監視プロセスを起こさないといけません。
プログラマー泣かせです。

匿名希望改め、ちゃいパパです〜

andi 1999/11/19(金) 17:31:15
なんか便乗?的な質問なんですけど
コンマで区切ってなくてもCSV形式って言うんですか?

じゅん 1999/11/19(金) 17:38:23
wosamuさん、ふじさん、ちゃいパパさん、色々と貴重なアドバイスありがとうございます。

>まだまったく作られていないのでしょうか?
>まずこれ以前にどのような環境で開発されるか考えられたほうがよいと思いますけれど。

すみません、またまた説明不足でした。
開発は、始めています。(生まれて初めてHTMLを使っての開発しています(^^;)。)

開発環境は、IIS4.0+ASP(VBScript)です。
ただし、NTServerのマシンは、まだないので、NTWorkStationのPWSで開発しています。

私の勉強不足でした。
あれから、色々とASP関連の書籍を見たら、クライアント側にテキストデータを書き出せないことがわかりました。

VisualBasicや、Access等の開発と同じイメージで質問してしまいました。

クライアントで行う画面操作の過程は、クライアントにMDBにワークテーブルを作成して、そのワークテーブルに対してデータの更新を行う。
最終的に、画面で更新ボタンを押下すると、ワークテーブルの内容で、サーバーのDBを更新する。

と言うように考えていた訳です。
結果的に、ちんぷんかんぷんな質問をしてしまいました。
申し訳ありません。

そうすると、サーバー側に、テキストファイル又は、DBのワークテーブルを使用することになるってことですね。

>#データの保護、一元性の確保等については DB に任せた方が
>#良いでしょうから。

その通りですね、DBのワークテーブルにしようかな。
やっぱり、テキストファイルは、ちょっと不安(^^;)。
データを書き込む利用者を一意に識別する方法を考えなければ....

後は、Sessionオブジェクトの配列にする方法もあると思うのですが、明細の追加、更新、削除する度に、配列を操作するとなると、面倒ですね。

もう少し、検討してみます。

ふじ 1999/11/19(金) 17:44:26
>コンマで区切ってなくてもCSV形式って言うんですか?
CSV = Comma Separated Value
だから、タブ区切りだと CSV じゃないですね。TSV かな。

wosamu 1999/11/19(金) 18:30:03
NTだってことはDBはSQLSERVERの可能性が高いかな。
どうやら一時的に何らかの方法で保存してDBに一括して登録するというのを
考えておられるみたいですけど、登録の結果がリアルタイムには
反映されなくてよろしいのでしょうか?

じゅん 1999/11/19(金) 19:15:18
>NTだってことはDBはSQLSERVERの可能性が高いかな。
データベースは、Oracle8を使用しています。

>考えておられるみたいですけど、登録の結果がリアルタイムには
>反映されなくてよろしいのでしょうか?

一時保存した結果から、DBへ更新するタイミングとしては、各社員が一日分の日報を入力して、
送信ボタンの押下時に実行しようと思っています。

なので、送信ボタンを押下する毎に、DBに更新します。
これで、ほぼリアルタイムになるかなと(^^;)。

クライアント側に一時保存したかった理由は、サーバー上に共通ワークテーブル又は、共通テキストファイルを
一時保存に使用すると、各社員を識別する仕組みが必要になるからです。

それで、クライアントに一時保存できれば、その仕組みが必要なくなるなと思った訳です。
(Accessのサブフォームとワークテーブルをリンクしたようなイメージ)

Web開発の経験が無いこともありますが、Webの設計って、難しいですね(^^;)。

[上に] [前に] [次に]