テーブルの設計 その４"トランザクション"

■ くだり（ｲﾗﾈﾀﾞﾛ…）

前回は説明が下手くそで、ﾎﾝﾄｽﾏﾝｶｯﾀｯ!

動画で説明したほうが分かりやすいと思ったりしましたが、動画編集って大変なんですよね、トリミングしたり、タイミング合わせたり、エフェクト入れたり、文字情報いれたり、流石に動画編集する時間の確保が難しくて💦
（なんのために専用のようつべの垢作ったんだ説）

ま、今回も同じ感じになるかもしれません。（いやなる、確信）

■ データの更新方法とデータの格納方法

データを格納するテーブルを考えた後、データの流れや処理方法を考えて、もう一度、テーブルの追加・削除・変更を考えていきます。

ワイのような、実務の合間にツールを作るとなると、開発コスト（時間です）の重要性って高いです。
要するに、出来る限りシンプルに作る。

下記の項目は、ワイが長年の経験値で、考慮するポイントになる。
Accessでツールを作る時に考えるポイントです。

　> 何人で使用するのか？
　> 登録・更新・削除の頻度は？
　> 他のテーブルに与える影響は？
　> 開発難易度（開発期間）はＯＫ？
　> データの保存期間は？
　> トラブル時のリカバリは？

これらの注意事項を、深く考慮して決定します。
一つ一つ、考えていきます。

| 何人で使用するのか？

基本的に１名。

| 登録・更新・削除の頻度は？

登録は、朝と昼と夕の３回。
ごく稀に、１～２件のマニュアル登録。
口数が増えると、レコードが追加。

更新は、運賃を計算させる時の１回み。
ただし、全レコード。多くて４００レコード数くらい。

削除は、Ｒ／３に送料をアップデートした時のみ。
個別のレコードの削除は、基本無し。

シンプルな設計で済みそうだ。

| 他のテーブルに与える影響は？

ここで言う「他のテーブル」の意味は、「他のツールのテーブル」という意味です。

このツールで、他のテーブルに影響は無いが、たのツールよりデータをもらう予定なので、読み取り専用ではあるが、影響を受ける可能性がある。
ただ、どちらにせよ、基幹システムが大きく変化しない限り変更する予定が無いので、ほぼ影響なしと判断する。

| 開発難易度（開発期間）は？

開発工数にかける時間は最小限にする必要あり。
作りをシンプルにしつつ、機能は果たすように品質を維持する。
テーブルは、少なくする必要あり。

| データの保存期間は？

データ自体は、Ｒ／３にアップデートされるので、基本的に残す必要性は無い。

しかし、マスターの設定ミスで、運賃を間違い登録される可能性があるので、処理した結果のデータは、保存した方が良い。

| トラブル時のリカバリは？

Ｒ／３からダウンロードしたテキストデータさえあれば、なんとかなる。

データ更新で大きなミスをしても、データをインポートしてリセットできるように作り込むこと。

■ トランザクション処理方法

特に重要なポイントは、利用する人数と、更新頻度。
この２つのポイントで詳細設計の方針が決まります。
ここでは、テーブルの設計段階なので、テーブルの設計について書きます。

利用人数単位での考え方

更新頻度単位での考え方

小さくて ﾎﾝﾄｽﾏﾝｶｯﾀｯ! 

今回は、本当に小さなアプリなことが分かります。
処理用のテーブルはほぼ不要で、Accessファイルを分割する必要もないと判定できます。

■ Access内のデータの流れを考える

基本方針が決まったら、もう一度データの流れを見直しします。

Accessファイルの切り分け

えっ！ポイントの表と違うじゃんって思う人もいたかもしれない。

１人しか使わないとしても、データとアプリは分けた方が良いです。
Accessのファイルを複数に分けても、開発コストには影響は無いです。

所詮、Accessなわけで、破損するリスクは付きまといます。
その破損した時のリスクを最小限に抑える為、Accessでアプリを作るなら、データとアプリを分離した方が良いです。

■ 処理用のテーブルは？

今回のアプリの利用者数は、基本的に１名なので、テーブルを直接参照して処理をするように作り込みます。
もう一つの主な理由、開発コストを抑える為。

テーブルを増やせば、それだけ処理が増えるし、同じような処理を２回、３回と作る必要があるからです。

個人的な考えですが、利用者が１名の場合、処理用テーブルは作る必要は無いと思います。

ただ、２名以上となると、更新や削除する時は、注意が必要になります。
Accessはページロックが基本なので、データロックする可能性があり、処理用テーブルは必須になってきます。

さらに、データの整合性を保つ工夫も必要になって、ＶＢＡのプログラミングが大変な量になったり、色んなギミックを仕込む必要性も出てきます。

トランザクションを作るのも良いですが、作る前に一呼吸。

アプリの特性を理解し、開発コストも考えて、テーブルの設計をすることが一番です。

■ まとめ

処理用テーブルはここまで。
（テーブルの設計は、あと２回）

次回は、マスターテーブルについて、深堀します。

このアプリの保存データについて、何かアプトプットを出すのかと言われたら、「特にない」ってなるので、この辺の説明は、どうしても薄くなってしまう問題があります。
正規化の所も薄い内容なのは、データを利用しないアプリだからでしょうね。
仕方がないです。

役に立っているのかは、微妙ですが、一人でもアプリを作る人に参考になれればと思って、記事を継続しています。

今回も、こんな薄い内容で ﾎﾝﾄｽﾏﾝｶｯﾀｯ 。

ここまで、読んでくれて、ありがとうございました。
では、また次回。