- ベストアンサー
AS/400のDBについて
現在オフコンで基幹業務管理しております。 得意先のマスタの項目を何項目か追加するよう情報システム部に依頼を出したところ フィールドの桁数の制限を既にオーバーしている為、これ以上追加するわけにはいかない???、との回答であっさり却下されてしまいました。意味が不明な為、よく追求すると、マスタ全体に桁数制限があり、現状その限界まで来ているとの事でした。オフコンの世界は良く分からないのですが、その追加する項目だけ別なテーブルに分けて対応することは不可能なのでしょうか？
- hikson
- お礼率41% (139/338)
- その他(データベース)
- 回答数7
- ありがとう数2
- みんなの回答 （7）
- 専門家の回答
質問者が選んだベストアンサー
#2です。 ＞プログラムの分だけ変更が必要になるということですか？ プログラムの変更をしなくても、物理ファイル又は論理ファイルが 変更されたときはコンパイルという作業を行わないとプログラムが エラーとなり動きません。 ＞あたらしいテーブルを作成するということですか？ オープン系でいうテーブルＡＳ／４００では物理ファイルといいますが キーとなる項目（ここでは得意先ＣＤ）と追加したい項目だけ別の 物理ファイルを作成し、プログラム内でその項目を見に行くときは 得意先マスタではなく、新しいファイルを見に行くようにすることで 得意先マスタを変更するよりも楽に項目の追加の様なことはできます。 ＞後のメンテナンスとはどういったことですか？ 後でプログラムの変更などがあった場合など、プログラムの仕様を 調べる必要があるときに、意味も無く行き当たりばったりのファイルを 多く使用していると、見づらく、理解するのに時間がかかり、 余計な時間をとられてしまいます。 ※ＡＳ／４００ではファイルの読み書きのタイミングが結構 難しいためファイル数が多いとそのときの状況をイメージするのに 苦労します。
その他の回答 (6)
- JACK_TOSHI
- ベストアンサー率63% (12/19)
>#6 です。 >＃4の方が項目を追加することによって、最も作業工数のかかる部分としてあげられた、既存プログラムへの影響を防ぐことは可能ですか？ その増やした項目は、キーを指定して別テーブルから情報を取得するので可能ですが、それでも得意先マスタ登録・更新・削除プログラムは、変更しなければならない（その追加項目のみのサブ画面を配備するのが簡単でしょう）。
補足
ご意見ありがとうございました。その追加項目のみサブ画面にすれば影響を軽減できますね。
- JACK_TOSHI
- ベストアンサー率63% (12/19)
>その追加する項目だけ別なテーブルに分けて対応することは不可能なのでしょうか？ ＡＳ／４００のデータベースもＲＤＢＭＳ（ＤＢ２／４００）可能ですよ。良く使用する方法です。あまりテーブルを細かくし過ぎると好ましくない場合もありますが。 >オフコンの世界 Ｘ８６系ＲＤＢＭＳ（MySQL, PostgreSQL, DB2_expressC) 有料RDBMS と方言はありますがＳＱＬ文の基本は同じです。 テーブル：物理ファイル（ＰＦ） ＳＱＬ文：論理ファイル（ＬＦ）のコンパイルが発生するのが唯一違う処でしょうか・・・・・コード形態もunicodeでは無くEBCDICですね。
補足
ご意見ありがとうございます。テーブルを分けることにより ＃4の方が項目を追加することによって、最も作業工数のかかる部分としてあげられた、既存プログラムへの影響を防ぐことは可能ですか？
- legacy_bp5_20r
- ベストアンサー率23% (400/1688)
なんか微妙に噛み合ってないですね。 項目（フィールド）の追加で既存フィールドの桁数とは無関係と思う。 数字タイプなら３２桁、文字タイプなら２５６桁、とかいけますよ。 ”フィールド長”ではなく”レコード長”との勘違いであれば、あり得なくはない。 ＤＢ拡張は作業工数を度外視しても構わないなら大した手順ではないが、費用対効果の検討は必ずついて回るので、技術的な問題だけではすまないとは思いますが。。。 ＤＢの拡張手順は以下の通り １．得意先マスタの定義ファイルへ項目追加を行う。 ２．新得意先マスタで追加された項目を影響の出るプログラムへ修正を入れる ３．旧得意先マスタのバックアップをとる。 ４．旧得意先マスタの論理ファイル（ＬＦ）を削除する ５．旧得意先マスタの物理ファイル（ＰＦ）を削除する ６．新得意先マスタの物理ファイル（ＰＦ）を作成する ７．新得意先マスタの論理ファイル（ＬＦ）を作成する ８．新得意先マスタへ旧得意先マスタをバックアップから戻す ９．得意先マスタを使っているプログラムを全てコンパイルしなおす まずは、テスト環境などで検証してから、本番環境で実施します。 ２～８はユーザーが使わない時間（深夜や休日など）に行います。 これで一番時間がかかるのは項目２の部分で、システム規模にも寄りますが、影響度調査とプログラム修正で結構な時間がかかります。でも本当の目的は、追加した項目を有効利用するためのプログラムの開発でしょうから、ＤＢ拡張だけの時間では済みません。 また、別のテーブルを作成との事ですが、管理したり既存プログラムへの修正をする事を考えると、可能な限り１つにまとめるべきです。知識も無い・お金も無い・人もいない・時間も無い、などの無い無い尽くしになった時にだけ行われる最終手段という位置づけた方が良く、情シス以外が提案すべき内容ではない。
補足
参考になる、回答ありがとうございます。 おそらくレコード長の勘違いです。オープンシステムとは違い、作業工数の多さが目に見えてよく分かりました。
- toshi_2000
- ベストアンサー率30% (306/1002)
#1です。 テーブルの種類によっては、細かく正規化していると思いますが、得意先マスタのようなマスタ類は、あまり細かく正規化していないのでしょう。
お礼
ご意見ありがとうございます。
- taranko
- ベストアンサー率21% (516/2403)
可能か不可能かと問われると可能です。 ＡＳ／４００のファイルの項目追加・桁数の変更は簡単にできる ものではありません。得意先マスタともなるといろんなところで 使用されているため相当の手間となります。 物理ファイルを変更する場合、それに伴うコンパイルされた論理 ファイルをすべて削除し、物理ファイルを変更・コンパイルした後 論理ファイルのコンパイルをしなおし、これらの物理・論理ファイル が使用されているプログラムをすべてコンパイルしなおすという 作業が必要になります。 これを考えると、新しくファイルをひとつ作成したほうが簡単に やりたいことができるとは思いますが、後のメンテナンスなどを 考えると極力とりたくない方法です。
補足
ご意見ありがとうございます。 >いろんなところで使用されているため相当の手間となります。 使用されているプログラムの分だけ変更が必要になるということですか？ あたらしいテーブルを作成するということですか？後のメンテナンスとはどういったことですか？ 教えてください。 くどくどと聞いてすみませんがご教授お願いします。
- toshi_2000
- ベストアンサー率30% (306/1002)
マスターに入れるべき項目を別テーブルで管理するとなると、システムの大幅な見直しが必要になると思われます。 全く不可能というわけではなく、変更のための工数、その後のメンテナンスのために工数も非常に多くなることが予想されます。
補足
ご回答ありがとうございます。オープンシステムの場合DBはなるべくシステム設計の柔軟性を考慮してテーブルを細かい単位に正規化すると聞いておりますが、一概には言えないということでしょうか？
お礼
わかり易くご説明いただきありがとうございます。 よく、理解しました。