みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
いつもお世話になっております。
よくあるパターンをご質問させていただきます。
商品マスタ
└主キー
└商品名
伝票明細
└主キー
└商品外部キー
└ルックアップ_商品名
という構造があり、商品マスタに商品Aを追加し、明細にその商品を追加しました。
ルックアップで、商品名が引っ張られました。
その後、商品Aという商品名が誤ちであったことに気づき、商品マスタの商品名”商品A”を商品Bに変更しました。
この際に、データベース保持、保全的な対応は次のうち、どれでしょうか。
1.明細を削除して、作り直していただく
2.明細に再ルックアップを行うボタンを配置する
3.その他
よろしくお願いします。
明細テーブルで、商品名を使ってレコードを抽出したり集計する機会は多々ありますか。
そうでなければ、フィールドは作らず、マスターを参照するだけでいいのでは。
Offline
私なら、とりあえず手作業で以下の対応を行います（3.その他）。
１）バックアップ作成
２）商品外部キーで明細テーブルを検索し、修正対象の明細レコードを抽出
３）再ルックアップ／あるいはフィールド内容の全置換で商品名を"商品B"に変更
（商品名だけルックアップしているなら再ルックアップで良いですが、価格等もルックアップしていると思わぬ影響も？）
1.は登録モレの危険があるので避けたい（というか、それを防ぐために件数カウントするなら上記の方法が楽ですね）。
2.はスクリプト化しても、再利用の可能性が低そう。
Last edited by koeda (2019-10-30 10:21:02)
Offline
Shinさん
誤りでない場合（商品名が途中で変更になった場合）などに備えて、明細テーブルに商品名をルックアップしています。
その他、検索なども行う都合上、速度を考慮して、そういった仕様です。
koedaさん
ということは、誤って伝票を作成するたびに、こちらのサービスで修正を行うということですね。
顧客が多くなればなるほど、そういった要件の要望が増えて、大変になりそうです。
マスタの商品名の変更を手作業ではできない様にしておいて、
スクリプトで、
商品名変更
関連レコード抽出
商品名再ルックアップ
とし、
そのボタンを配置すればいいのでは。
Offline
チポさん
それだと、単純な変更の際も過去の分を全て上書きしてしまいそうです。
間違いか、変更かを検知するのは厳しそうですが・・・。
> 2.明細に再ルックアップを行うボタンを配置する
こう書かれていましたので、
過去関連レコード全て変更するものと思いましたが、、
変更できる者を限定するとか、
もちろん、安全には配慮するべきですよ。
> 単純な変更の際
これではない変更も有るということですか？
その違いはどこで？
Offline
ということは、誤って伝票を作成するたびに、こちらのサービスで修正を行うということですね。
顧客が多くなればなるほど、そういった要件の要望が増えて、大変になりそうです。
マスタ登録の「ミス」（＝滅多にあってはならないこと）の前提で回答しましたが…
それでお金をいただけるのであれば、それもアリかと笑
正常な運用の範囲でもユーザ自身がマスタを変更する機会が多く、過去に遡って明細に反映する必要があるのなら、「マスタメンテナンス機能」としてその仕様を明確にして予め作り込む必要があるでしょう。
そんな開発予算がない、あるいは都度修正で対応できる程度の頻度なのであれば、手順書だけ作ってユーザに自己責任で修正してもらうとか、メンテナンス要員が用意できないなら有償でサポートするとか。
当然ですが、有限な予算の中で完璧な機能や運用体制を構築することは不可能なので…（FileMakerに限った話ではありませんね）
＃「ビタ一文払いたくない」というユーザーには、1.をお願いするしかないですねぇ
Last edited by koeda (2019-10-30 13:06:28)
Offline
もう少し建設的（？）な話として…
商品マスタとか顧客マスタのように、運用中に変更される可能性の高いマスタのキーは主番号／枝番号のように２重のキーを持たせ
001／001 商品A 100円 2019/02/01 初期登録
001／002 商品B 100円 2019/02/10 商品名変更
001／003 商品B 110円 2019/08/01 価格変更
のように、管理するのはどうでしょう？
主番号で検索・集計すればこれら３つは同じ商品として扱えるし、明細とは枝番号まで含めてリレーションすれば変更履歴との整合性を保ちやすい。
同じ製品の色違い／サイズ違いとか、品番に枝番号をつけて管理することがありますが、同じように変更履歴に枝番号を振るという案です…
（追記）有効・無効のフラグ管理も必須になりますね
Last edited by koeda (2019-10-30 13:43:25)
Offline
> 明細テーブルに商品名をルックアップしています。
普通は、その修正時点でのマスターのデータが正しい、と看做して再ルックアップさせるでしょう。
商品名が AAAa が誤っていて、AAAA が正しい時、全てを修正することになりますね。印刷した伝票との相違がでますが、それがどうなんでしょう。検討が必要です。
また、修正歴を作っていきます。価格、品番など変更されうる項目を別テーブルに置き、変更のタイムスタンプを持たせます。参照した時点で、それより過去のタイムスタンプのレコードの中の最新レコードを参照すれば、その時点での最新情報となります。
> その他、検索なども行う都合上、速度を考慮して、そういった仕様です。
部分一致検索も行なっているのですか。全一致検索のみでしたら、値一覧で商品名から商品コードを入力させ、検索させるのが最速です。
また、スタンドアロンでしたら、参照レコードでも検索でもほとんど差は出ないですし、ローカルのサーバー環境でも対象レコードが膨大で無ければ、参照フィールドの検索でも初回検索の1秒程度の差以外は目立たないですよ。（AWSでは別です）
Offline
チポさん
再ルックアップというのは現在参照している明細のみを対象とします。
誤った場合と、そうでない場合（例：商品名が変更された 等）の検知が難しいので、対応に悩んでいます。
koedaさん
枝番でのレコードのバージョン管理的なことは過去もしましたが、かなり複雑になり苦しかったです。
手動でやってしまうのが楽で早いのでWinWInではあるのですが・・・。
Shinさん
つまり、AAAaが誤り、AAAAが正しいとなった場合は、再ルックアップのボタンを作成して、参照している明細を再ルックアップされますか？
あるいは、手動での対応をされますか？もちろん、ケースにも寄ると思いますが・・・。
検索に関してはAWSなので、関連レコード先を検索すると明らかに速度が遅くなります
また、商品名の部分一致でも検索させるので厳しいかもしれません。
AWS でしたらルックアップにしないと仕方ないですね。
商品名が改訂された場合は、別コードにする運用を考えられてもいいかと思います。または、変更歴を持たせておき、変更日を含めたリレーションにするといいのでは。
データの訂正は、変更歴を持たせていない場合には、商品コードを使って商品マスターから明細へ関連レコードへ移動 を行います。その後、誤データ文字列を正データ文字列に置き換える全置換を行うのがいいのでは。
データの訂正は一般ユーザーが行う作業ではないので、スクリプトにしておいてもいいでしょうが、ボタンにはしないでしょう。
変更歴があるのでしたら、関連レコードへ移動、再ルックアップ でいいでしょう。
Offline
Pages: 1
[ Generated in 0.006 seconds, 7 queries executed - Memory usage: 545.88 KiB (Peak: 566.41 KiB) ]