桐質問掲示板 [One Topic All View / Re[3]: フォームを作りたい / Page: 0]

(現在過去ログ76 を表示中)

[ 親記事をトピックトップへ ]

このトピックに書きこむ

過去ログには書き込み不可

■11535 / inTopicNo.1)

　Re[5]: 悲しげさん江

▼■

□投稿者/ ONnoji -(2018/10/27(Sat) 23:51:56)

> （１）マスター表（商品マスターとか仕入先マスターとか）
> （２）伝票入力用作業表
> （３）入力データを転記保存するための保存表（仮に「＊＊台帳」と呼んでいる）
>
> たいていはこの３つの表で回しています。
> 付随する処理は上記（３）のデータから抽出したものを諸々加工しまくる。

データファイルを、台帳に例えることがありますね。

私も僅かな業務アプリケーション作成の経験の中で、

取扱説明書に「○○○台帳」や「×××台帳」といった呼称を用いたことがありました。

事務作業の機械化のためにパソコンを利用するのですから、昔はリアルな台帳が存在していることが多かったのです。

なので、「ほにゃらら台帳」という言葉が飛び交っても、プロジェクトの誰にでも理解できました。

しかし、いったん事務作業の機械化が完成してしまうと、

つまり、業務アプリケーションが完成してしまうと、

ハードディスクに保存されているファイルを「ほにゃらら台帳」と呼ぶのに違和感が生じてきます。

ということで、最近では、「○○○トランザクション」や「×××マスタ」と、データの種類によって呼び方を変えています。

直近のプロジェクトの場合には、○○○トランザクション.tbl や ×××マスタ.tbl とファイル名そのものにデータの種類を明示しています。

なお、オペレータには、トランザクションデータとマスタデータの違いを口が酸っぱくなるまで説明してあります。

引用返信 [メール受信/OFF] 削除キー/

■11534 / inTopicNo.2)

　Re[4]: 悲しげさん江

▲▼■

□投稿者/ 悲しげ -(2018/10/27(Sat) 23:24:57)

■No11521に返信(ONnojiさんの記事)
この話題をこれ以上ひっぱるのも何ですが・・・・(^^;)(^^;)(^^;)
あまり難しいことは（特にカタカナ語）は実は判らないままに、私は我流でやってきまして(^^;)、
まあ、それはそれでひとつの有効なスタイルではないかと思っていたりします。

（１）マスター表（商品マスターとか仕入先マスターとか）
（２）伝票入力用作業表
（３）入力データを転記保存するための保存表（仮に「＊＊台帳」と呼んでいる）

たいていはこの３つの表で回しています。
付随する処理は上記（３）のデータから抽出したものを諸々加工しまくる。

このスタイルをどうして採用するようになったかは、今となっては思い出せませんが(^^;)、
おそらく「浦秀樹本」の影響が大きいように思います。あとpc-van、nifty-serveも。
「桐使い」は親切な人が多かったし。

引用返信 [メール受信/OFF] 削除キー/

■11532 / inTopicNo.3)

　Re[3]: 一応できました（３本目）

▲▼■

□投稿者/ 悲しげ -(2018/10/27(Sat) 23:01:13)

■No11525に返信(悲しげさんの記事)

締めた後ですが、横（商品番号）を固定した処理を執念深く考えてみました。
当初の例示が下記のようだったので。

地区01 地区03 地区05 地区08 地区09 地区10
003 　2 　※5 　※19 ※108 　34 　689

結構悩んだ末のかなりの力技です。
まるでゲームのような感覚で作ってみました。
実務だとこんなふうにはしないだろうと思いつつ。(^^;)

3souatariyoko.zip/9KB

引用返信 [メール受信/OFF] 削除キー/

■11531 / inTopicNo.4)

　Re[3]: フォームを作りたい

▲▼■

□投稿者/ ド初心者 -(2018/10/25(Thu) 13:00:43)

悲しげ様ほか、皆様、ありがとうございました。

正直悲しげ様のサンプルは、高度すぎてまだ理解できていない
のですが、これ以上の解決もないので、一応レスを締めさせて
頂ければ、と思います。
ありがとうございました。

>

解決済み!

引用返信 [メール受信/OFF] 削除キー/

■11530 / inTopicNo.5)

　Re[2]: フォームを作りたい

▲▼■

□投稿者/ ONnoji -(2018/10/25(Thu) 12:06:15)

2018/10/25(Thu) 12:24:08 編集(投稿者)

横レスで大変失礼します。m(__)m

> マスタ項目とかにしとけばよかったのかな

項目の名称の問題ではないですよね。

データの質の問題でしょ。

実際のデータは提示したくないので、その替わりに、

｛商品名,地区01,地区02,地区03, ･･･地区20 ｝

↑このような、仮のサンプルを提示されたのかもしれませんね。

本当はアンケートのデータで

｛氏名,質問01,質問02,質問03, ･･･質問20 ｝

なのかもしれません。

しかし、今までのやり取りを見る限りアンケートのデータではなさそうですね。

ちなみに、アンケートデータは参照するデータではなさそうなので、マスタとは呼べませんね。

引用返信 [メール受信/OFF] 削除キー/

■11529 / inTopicNo.6)

　Re[6]: フォームを作りたい

▲▼■

□投稿者/ ONnoji -(2018/10/23(Tue) 19:33:35)

2018/10/23(Tue) 20:01:48 編集(投稿者)
2018/10/23(Tue) 19:59:29 編集(投稿者)
2018/10/23(Tue) 19:39:40 編集(投稿者)
2018/10/23(Tue) 19:36:56 編集(投稿者)
2018/10/23(Tue) 19:35:11 編集(投稿者)

> ちょっと疑問なのですが
> どうやって正規化してあるのですか？

質問者がどのように正規化してあるのかは、全く不明です。

しかし、私は、マスタデータではなく、トランザクションデータからデータを導出するのが正しい運用方法だろうと睨んでいます。

いわゆる、縦横変換ですね。

現状は、ただの電子的な紙ですね。だから、表計算ソフトで処理した方がよいのではないかと思っています。

　◇　◇　◇　◇　◇　◇

> どうやって正規化してあるのですか？

ひょとして？、正規化が不十分だというご意見でしょうかね？？？？

それでは、以下に誤解が非常に多い正規化の話題を…

ご承知のようにマスタデータは正規化します。これは当然ですね。

しかし、トランザクションデータは導出項目を含めて冗長を許して、完全に正規化しませんよ。

何故ならば、変更すると、改竄になってしまうデータだからです。※入力誤りを除きます。

この点をご存じない人が非常に多いので、以下に引用を示します。

詳しいことは、既出の　11521　悲しげさん江　投稿者/ ONnoji -(2018/10/21(Sun) 18:31:40)
http://tayu.o0o0.jp/bbs/kiri/cbbs.cgi?mode=one&namber=11521&type=11500&space=45&no=0

の引用を参照してください。

こちら
　↓
【引用】マスターデータとトランザクションデータって結局なんぞや – gomokulog
http://gomocool.net/gomokulog/?p=906

その他にもあります、こちらもお読みください。
　↓
【引用】ＲＤＢの正規化の方法と、正規化を崩す方法 - ウィリアムのいたずらの開発日記
http://blog.goo.ne.jp/xmldtp/e/2a35412416a6f9b56f194d69d09f94bb

【引用】データベースは正規化しない方がよい？ : makoto_fujimotoのblog
http://blog.shinkaku.co.jp/archives/19849328.html

> 見当違いでしたらすいません

巷に溢れかえっているｗｅｂページに見られるＲＤＢ教科書のように「盲目的に何でもかんでも正規化するというわけではありませんよ」というだけのことですよ。

ｐ．ｓ．

> ONnojiさんは、結合表もメインサブフォームも使われない派？

必要があれば、結合表も使いますよ。

でも、私の場合には、トランザクションデータを処理することが多いので、結合表を使う機会が殆ど無いのです。

使う必要がないものは、使わないというだけのことですよ。

つまり、好き嫌いで結合表を使わないのではありません。キッパリ。

簡単なメインサブフォームも使うことがありますよ。

ただし、サブフォーム側でイベント処理は一切使わないというレベルのものに限ります。

基本的にメインサブフォームは使い難いので使いません。これは好き嫌いの話です。(^^ゞ

引用返信 [メール受信/OFF] 削除キー/

■11528 / inTopicNo.7)

　Re[5]: フォームを作りたい

▲▼■

□投稿者/ 尾形 -(2018/10/23(Tue) 17:20:24)

何度もすいません

わたしの記憶違いかもしれませんが
ONnojiさんは、結合表もメインサブフォームも使われない派？
だったように思います

ちょっと疑問なのですが
どうやって正規化してあるのですか？

見当違いでしたらすいません

引用返信 [メール受信/OFF] 削除キー/

■11527 / inTopicNo.8)

　Re[4]: フォームを作りたい

▲▼■

□投稿者/ ONnoji -(2018/10/23(Tue) 11:07:27)

2018/10/23(Tue) 11:24:43 編集(投稿者)

今までにも、項目数が１００個とか２００個とかという質問がありました。

大抵の場合、これは駄目だから、正規化しなさいとなるわけです。

ところが、今回は、「２００項目の表を訂正入力する楽な方法」の質問があったわけです。

当初は、訂正が必要なデータなのでマスタデータかと思ったのですが、

いろいろ考慮すると、トランザクションデータから縦横変換して導出するデータだと思われます。

縦横変換して導出したデータならば、必要時に、再び導出すれば最新の状態になるわけです。

つまり、「２００項目の表を訂正入力する楽な方法」そのものが本末転倒の思考なのです。

しかし、導出の元になるトランザクションデータがまったく考慮されていませんね。

ひょっとして、リアルな紙の２００項目帳簿で、消しゴム（インク消し）と鉛筆（ペン）を使って文字を書き換えているのでしょうか？

もしもそうならば、本当にトランザクションデータが無いことになりますが、

それでも、書き換えるためのデータを求めることが出来る原票くらいはあるのではないでしょうか？。

つまり、なんの根拠も無しに、書き換えたりしないでしょう。

まさにそれが、トランザクションデータに相当します。

なお、どうしても項目数が２００個の表で管理したいのならば、

データベースではなく表計算ソフトのワークシートの方が適していると思いますよ。

引用返信 [メール受信/OFF] 削除キー/

■11526 / inTopicNo.9)

　Re[1]: フォームを作りたい

▲▼■

□投稿者/ 尾形 -(2018/10/23(Tue) 05:54:01)

どうも、こんにちは

項目名に「地区」と書いちゃったんで

気の毒な感じになっちゃったですね (^^;

マスタ項目とかにしとけばよかったのかな

引用返信 [メール受信/OFF] 削除キー/

■11525 / inTopicNo.10)

　Re[2]: 一応できました（２本目）

▲▼■

□投稿者/ 悲しげ -(2018/10/22(Mon) 00:19:18)

■No11524に返信(悲しげさんの記事)
一度に2個のzipは挙げられないようなので、2本目です。

2souatari.zip/11KB

引用返信 [メール受信/OFF] 削除キー/

■11524 / inTopicNo.11)

　一応できました

▲▼■

□投稿者/ 悲しげ -(2018/10/22(Mon) 00:17:09)

2018/10/22(Mon) 00:31:23 編集(投稿者)

表が「トランザクション」か「マスター」かは置いといて(^^;)
(無理すじながら？)現構成のまま対応することを考えてみました。

で、編集（入力）のタイミングがふたつ考えられました。
（いつ訂正入力したかの値も入れたいですが、それは今回無視）

【１】下記のような入力値のセットが存在する場合
(1)商品番号、(2)地区番号、(3)入力する値
これを使って表に書き込むとすれば、
上記３項目入力用のフォーム（カード型）を用意する。
左の２つは、手入力でもいいけど、「商品(番号).tbx」と「地区(番号).tbx」から
検索取得するのがベター。
※zip1はataiset.zip（値セット方式、おまけとして地区番号取得.cmxも）
　"値セット.wfx"から実行する。

【２】そうではなく入力済み項目を総当たりで表示して任意に値を訂正入力する。
　　　（未入力項目は上記方式か？）
商品番号と地区番号の（云い換えれば縦と横）どちらが先でもよさそうだが、
先に地区番号項目を固定してから、入力済みの行を絞り込んで商品番号を表示させてみた。
[商品番号]とひとつの[地区番号]項目(可変)の一覧表フォームを用意して、
[地区番号]項目は前後に変更できるようにしてみた。
※zip2はsouatari.zip（総当たり方式）
　"総当たり.wfx"から実行する。

【PS】併合は使えない？
値が数値系ではなく文字列ということから、入力値の更新に加算や減算は使えず、全て複写となるため。(;_;)

*

いずれにせよ、かなりの力技です。
繰り返しになりますが、今後の運用のこともあるので、表の構成をこの際に抜本的に見直すことをお勧めします。

1ataiset.zip/25KB

引用返信 [メール受信/OFF] 削除キー/

■11523 / inTopicNo.12)

　Re[4]: むかしばなし

▲▼■

□投稿者/ まさやん -(2018/10/21(Sun) 18:54:27)

2018/10/21(Sun) 18:57:16 編集(投稿者)

> 或る時に別の他店の人がその存在を知り、２年越しで全店で採用に至った。
>
> ・・・こんなエピソードを思い出しました。

ＳＮＳでいう　『いいね』　です。

引用返信 [メール受信/OFF] 削除キー/

■11522 / inTopicNo.13)

　Re[4]: むかしばなし

▲▼■

□投稿者/ ONnoji -(2018/10/21(Sun) 18:40:04)

2018/10/21(Sun) 18:49:27 編集(投稿者)

>10年以上前ですが、次のようなエクセルのシートがありまして

まさしく、コンピュータ音痴のシートですね。

> 私が行くようになってから、こんなことやってられっかと、桐で仕入システムを作り上げました。
> そしたらエライ人（他店にいる）が激怒して、従来どおりでやれ、と。

エライ人って声がデカイだけで、頭を使わない御仁が非常に多いようですね。

パワハラの温床ですね。

> 説明を理解できる人ではなかったので、私はサラリと無視して暫く自店だけで運用していたのですが、
> 或る時に別の他店の人がその存在を知り、２年越しで全店で採用に至った。

それは慶祝ですね。

483×188 => 250×97

1540127482.jpg/18KB

引用返信 [メール受信/OFF] 削除キー/

■11521 / inTopicNo.14)

　Re[3]: 悲しげさん江

▲▼■

□投稿者/ ONnoji -(2018/10/21(Sun) 18:31:40)

2018/10/21(Sun) 22:00:42 編集(投稿者)
2018/10/21(Sun) 18:41:37 編集(投稿者)
2018/10/21(Sun) 18:33:25 編集(投稿者)
2018/10/21(Sun) 18:32:03 編集(投稿者)

> 寄り道コメントへの質問です(^^;)
>
> ところでここで言う「トランザクション」の意味というか、
> 「マスターとトランザクション」の違いについて、ざっくりと
> 教えていただけますか？
>
> 余のボキャブラリに「トランザクション」はなかったので、
> ネットでちょっと当たってみたが、よく判らなかった(;_;)。

まず、「トランザクション」でちょん切ってしまうと、

・トランザクション・プロセッシング（トランザクション処理）※ＲＤＢＭＳの標準機能

と、

・トランザクションデータ（マスタデータと対極をなします）※データの性質の区別

との、どちらなのか分からなくなりますので、省略しないことをおススメします。

今回取り上げているのは、トランザクションデータとマスタデータの方です。

新規に書くのは大変なので以下に引用させていただきます。

こちら
　↓
【引用】フォームアプリケーションの練習をする ( ソフトウェア ) - ブログ版－桐のイベント道場 - Yahoo!ブログ
https://blogs.yahoo.co.jp/siliconvalley_bay_7565/58233113.html

マスターデータとトランザクションデータを区別することが重要です。

この点が理解できていないと、変てこなデータ処理をしてしまいます。

こういう基本的な事柄は、桐関係の掲示板やＨＰで扱われることが殆どありません。

しかし、実はここがキモなんです。

マスターデータとトランザクションデータは桐固有の知識ではありません。

処理系にどんな言語を使おうと、どんなデータベースを使おうと知っておかなければならない基本知識です。

以下にネットで見つけた記事を引用しよう。

【引用】マスターデータとトランザクションデータって結局なんぞや – gomokulog
http://gomocool.net/gomokulog/?p=906

データベースに触れると、割とすぐに当たり前のように使われている言葉、マスターデータ(マスターテーブル)とトランザクションデータ(トランザクションテーブル) とはなんぞや。

色々解釈ありますが、私的には、

メンテナンスされ、常に最新なデータが反映されているのがマスタデータで、原則削除しないで履歴として残しておくデータがトランザクションデータです。

例えば、ネットで商品を購入し、その時の明細が以下のような感じだとします。

===================

4/20 注文番号 OR0000132

商品A (Item02001) 10000円 2個小計20000円
商品B (Item02002) 5000円 1個小計5000円

合計 25000円

===================

これは購入後マイページで、見れるとします。

その後、商品Aが思ったより売れるので、お店が12000円に値上げしました。

新たにECショップでみると、12000円で売られていて、「安いときに買えてよかった。」って経験ありませんか？

後から、マイページの購入履歴で見たとき、購入履歴の商品の値段が12000円になるわけが無いですよね？

このように、売る時には常に最新のデータを表示するためのデータがマスタデータです。
しっかりメンテナンスされて、もちろん正規化されています。

そして、売れた後に証拠として残されるべき情報がトランザクションデータです。
原則削除は行わず、キャンセルになった場合などはステータス情報などが、”キャンセル済み”などになります。
値段などはシステムのミスなどでなければ、改変することはありません。
このように、履歴、証拠として残しておくデータで、それ故、日ごろの業務(transaction)を行っていると増えていくデータといういみで、トランザクションデータというようです。

よく、日ごろの業務を行うとお客様データは増えていくから、マスタではなくトランザクションデータではないのかという疑問を抱くことがあるのですが、お客様が現住所を変更したら、変更しますよね。過去の住所は原則必要ないですよね？
このようにメンテナンスされていくのでマスタデータといえます。

まぁ、私も今でも、「あれ、これってマスタだっけトランザクションだっけ？」と迷うような曖昧なデータはありますが・・・、そこらへん慣れですかね。

ちなみに以前、データベースの正規化(正規形)とはなんぞやの最後の方で、正規化しないデータもあると書きましたが、まさにそれがトランザクションデータです。

例えば、注文テーブルなどは、第二正規化あたりでよく止めておきます。

上を第二正規化まで進める下記のようになる。

そして、多くはここから正規化を行わない。

なぜなら、第三正規化は、導出項目である小計や合計など、購入時(取引時)の値段を削除するからです。
また、第三正規化では、商品をマスタ化する必要があるが、商品名や商品の値段は変わる可能性があり、変わるたびに過去の購入時の金額や商品名も変わってしまうことになる。

まぁ、難しいこと考えずに消したら困るし変わったら困るなら、それ以上は何もしなければいいだけやね。

引用返信 [メール受信/OFF] 削除キー/

■11520 / inTopicNo.15)

　むかしばなし

▲▼■

□投稿者/ 悲しげ -(2018/10/21(Sun) 18:03:43)

■No11505に返信(ド初心者さんの記事)
10年以上前ですが、次のようなエクセルのシートがありまして
列（項目）は、
仕入先、品名、コード、仕入時の包装単価、1日、2日、3日、4日、・・・、30日、31日、金額※
で、毎日、当日仕入の個数を手入力するというもの。
金額は1日～31日の合計×包装単価として、当該品目の当月仕入計を掌握するため。
列は上述のように40個弱ですが、行が1000前後という・・・
品物の並びは1:仕入先、2:概ね品名順(漢字入りの雑なソート)
だから仕入先と独特の並び順を頭で覚えていないと探せない。(;_;)
探すのはもちろん目で(;_;)。
入力する列がずれてしまう（つまり20日の分を19日の列に入れてしまったり）こともしばしば。
その上、ひどいことに新商品があっても殆ど追加はしない(ﾟOﾟ)。
また仕入単価は時々変更になるが、殆ど修正されない（数年前のまま）。(ﾟOﾟ)
疑問もさほど持たずに、そのまま数年間運用されていたらしい。

私が行くようになってから、こんなことやってられっかと、桐で仕入システムを作り上げました。
そしたらエライ人（他店にいる）が激怒して、従来どおりでやれ、と。
説明を理解できる人ではなかったので、私はサラリと無視して暫く自店だけで運用していたのですが、
或る時に別の他店の人がその存在を知り、２年越しで全店で採用に至った。

・・・こんなエピソードを思い出しました。

引用返信 [メール受信/OFF] 削除キー/

■11519 / inTopicNo.16)

　Re[2]: 悲しげさん江

▲▼■

□投稿者/ 悲しげ -(2018/10/21(Sun) 17:15:03)

■No11514に返信(ONnojiさんの記事)

寄り道コメントへの質問です(^^;)

ところでここで言う「トランザクション」の意味というか、
「マスターとトランザクション」の違いについて、ざっくりと
教えていただけますか？

余のボキャブラリに「トランザクション」はなかったので、
ネットでちょっと当たってみたが、よく判らなかった(;_;)。

引用返信 [メール受信/OFF] 削除キー/

■11518 / inTopicNo.17)

　Re[3]: フォームを作りたい

▲▼■

□投稿者/ 尾形 -(2018/10/21(Sun) 11:47:40)

どうも、こんにちは

表形式で項目幅を小さくして、全項目画面に収めて

表示(V) → 拡張編集(V)
じゃダメかな

引用返信 [メール受信/OFF] 削除キー/

■11517 / inTopicNo.18)

　Re[2]: 悲しげさん江

▲▼■

□投稿者/ ONnoji -(2018/10/21(Sun) 10:05:58)

2018/10/21(Sun) 10:10:05 編集(投稿者)
2018/10/21(Sun) 10:08:47 編集(投稿者)

タラレバの続きです。

分かったような気がします。

>要は列が200列以上あって、逐一スクロールしてデータをメンテナンスするのが大変なのです。

↑これって異常でしょ。もしも、そう思わない人はコンピュータ音痴ですよ。

これって、神エクセルと同じ。つまり、コンピュータ音痴の方法論ですね。キッパリ。

　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇

データベースの場合には、

　取引などの事象
　　↓
　入力原票（いわゆる伝票類のこと）
　　↓
　キーボード等による入力作業
　　↓
　データ登録　←　参照：入力支援（各種マスタファイル）
　　↓　　　　　　※注意：トランザクションデータはマスタデータとリレーションしないこと
　　↓
　作業ファイル（日時更新・月次更新などで用いる）
　　↓
　　↓
　トランザクションファイル

↑上のような流れになるハズです。

そして、「列が200列以上あって、逐一スクロールしてデータをメンテナンスするのが大変な」表は、

　トランザクションファイル
　　↓
　有効データに絞り込み
　　↓
　配置表を出力　※作成方法はいろいろあるが、縦横変換なので、（何度も説明してきたように）結合表は使えない　

↑このように、トランザクションファイルから導出されるファイルなのです。

だから、マスタファイルではありません。

そして、そもそも導出ファイルなのですから、物品の種類が増えても対応できますし、数量の変更にも対応できます。

こうするべきだったのです。※「ブランド売るならブランディア」みたいな。

ところが、ぎっちょんちょん、悲しいかな神エクセルです。

作業が大変ですし、間違えもあるでしょう。

そして、何よりもオペレータがコンピュータの奴隷のようにコキ使われてしまいます。

それでは駄目なんです。

オペレータが楽に操作して、コンピュータを支配しているようなフィーリングを持たせることが大事なんです。

これというのも、すべて「神エクセルしか知らない無知」の産物なんですね。

全部タラレバですよ。(^^ゞ

引用返信 [メール受信/OFF] 削除キー/

■11514 / inTopicNo.19)

　Re[1]: 悲しげさん江

▲▼■

□投稿者/ ONnoji -(2018/10/20(Sat) 13:11:40)

2018/10/20(Sat) 13:20:20 編集(投稿者)
2018/10/20(Sat) 13:16:33 編集(投稿者)

悲しげさん江

寄り道の話なので、遠いところに投稿しました。

ちょっと以下を読んでみて下さい。

> >でも、すいません、テーブル構成自体は、私が決められないので、これはどうしようもありません。
> >要は列が200列以上あって、逐一スクロールしてデータをメンテナンスするのが大変なのです。
>
> 解決への一番の近道は、テーブル構成自体を「正規な形」に変えることです。
> 云い換えれば、そのように「決定権のある人」を説得することです。
>
> 「正規な形」ってのは、俗っぽく言えば「横のものを縦に」です。(例えばNo11502や後述のような)。

項目数が２００個以上ってどんなデータなんでしょうかね。

ひょっとすると、トランザクションデータではなくて、マスタデータなのかもしれませんね。

そもそも、トランザクションデータならば、変更の必要がないですからね。

変更しちゃったら、過去を書き換えることになっちゃう。

となると、マスタデータということになる。

しかし、未定義値が沢山あるマスタデータのようだから、あまり見かけないタイプなんでしょうね。

｛物品名,配置先１,配置先２,配置先３, ･･･配置先ｎ｝

例えば、物品マスタデータ、つまり配置表です。

※後述のように単なるトランザクションデータからのアウトプットで、本来の意味のマスタデータでは無いと思いますが…

　物品名　　　Ａ町　　　Ｂ町　　　　
　消火器Ａ　１０個　　１０個　･･･
　バケツ　　１０個　　１０個　･･･
　乾パン　　１０個　　１０個　･･･

こんなデータなのかな？　この例は、防災備品の想定だけどアリガチかな。

でも、物品配置の記録、つまりトランザクションデータもあるでしょう。

日付　　　　物品名　　数量　消費期限　　配置先　
yyyy-mm-dd　消火器Ａ　１０　yyyy-mm-dd　Ａ町
yyyy-mm-dd　消火器Ａ　１０　yyyy-mm-dd　Ｂ町
yyyy-mm-dd　バケツ　　１０　yyyy-mm-dd　Ａ町
yyyy-mm-dd　バケツ　　１０　yyyy-mm-dd　Ｂ町
yyyy-mm-dd　乾パン　　１０　yyyy-mm-dd　Ａ町
yyyy-mm-dd　乾パン　　１０　yyyy-mm-dd　Ｂ町
　：　　　　　：　　　　：　　：　　　　　：
　：　　　　　：　　　　：　　：　　　　　：
　：　　　　　：　　　　：　　：　　　　　：
　：　　　　　：　　　　：　　：　　　　　：

こういうトランザクションデータを用意して、マスタデータを併合するというのがマトモナ運用方法なのでしょうね。

※そもそも、単なる配置表が必要ならば、トランザクションデータの消費期限内の物品データを使って、配置表を出力すれば良いだけでしょうね。

しかし、トランザクションデータを使わずに、マスタデータを人力手動でメンテナンスする。

だから、オペレーションする人間が疲弊する。

こんなストーリーなのかもしれませんね。

全部タラレバですけどね。(^^ゞ

引用返信 [メール受信/OFF] 削除キー/

■11511 / inTopicNo.20)

　Re[3]: フォームを作りたい

▲　■

□投稿者/ 悲しげ -(2018/10/20(Sat) 00:36:37)

■No11505に返信(ド初心者さんの記事)
>でも、すいません、テーブル構成自体は、私が決められないので、これはどうしようもありません。
>要は列が200列以上あって、逐一スクロールしてデータをメンテナンスするのが大変なのです。

解決への一番の近道は、テーブル構成自体を「正規な形」に変えることです。
云い換えれば、そのように「決定権のある人」を説得することです。

「正規な形」ってのは、俗っぽく言えば「横のものを縦に」です。(例えばNo11502や後述のような)。

*

ところで「データをメンテナンスする」って何をやるんですか？
例えば、「毎日」または定期的な「或る日」に
「商品001」について、「地区01」の値を変更入力し、「地区02」の値を変更入力し、「地区03」・・・・
次に
「商品002」について、「地区01」の値を変更入力し、「地区02」の値を変更入力し、「地区03」・・・・
（いや「商品002」は「地区03」と「地区06」と「地区091」・・・なのかもしれない）
「商品003」について・・・・・
・・・・・・

とすれば、私なら入力作業用のフォームを用意して
(1)商品番号を指定し
　(商品.tbxから選ぶ)
(2)地区を指定し
　(地区番号.tbxから選ぶ)
(3)必要な数字を入力し
(0)でも最初に入力年月日とか伝票番号を入力するのが先かな？

そしてその結果を「何らかの方法で」マスター的な表に転記する。
この方法は幾らでもあるはずです（表の構成がまともでさえあれば）。
例えば、表の構成がお示しのような「まともじゃない」(^^;)場合でさえも
[商品番号]項目で指定された商品番号値のレコードを検索して、
指定の地区番号項目で、入力された数字(的文字列)に「行訂正」する。

*

仮に商品の種類が50で、地区が200あるのなら
商品を横に、地区を縦にする方がよいかもしれない。
それでも私ならそんなエクセルみたいな表は作りたくない。

*

ありうる（まともな）台帳的tbxの形

伝番　　年月日　商品番号　(商品名)　地区番号　数量　備考
0001　2018/01/20　001　　○○○○　　018　　　　8
0002　2018/01/20　007　　××××　　123　　　　5　　※
・・・・・
0072　2018/01/21　033　　▽▽▽▽　　005　　　109
・・・・・

横（項目）はせいぜい10～20くらいで
縦は無限大的に。(^^)v

このような形ならば、検索も絞り込みも集計も印刷も・・・諸々自由自在。

って、キリがないのでやめます(^^;)

ps.
引用は、全文ではなく、必要最小限に願います。

引用返信 [メール受信/OFF] 削除キー/

次の20件＞

トピック内ページ移動 / << 0 | 1 >>

HOME HELP 新規作成新着記事トピック表示ファイル一覧検索過去ログ

- Child Tree -
- Antispam Version -