システムのコードについて

質問

システムのコードについて

多チェーン店舗を持つ会社で、北海道や東北といったように、店舗をまとめてエリアと呼んでいます。
ACCESSで、簡易システムを組む場合、エリアと店舗はそれぞれコード化しているのですが、それがすべて数字のみで定義され、桁数も固定して変わる可能性が無い場合でも、コードは、ＤＢ上の項目定義を文字型で持つ方がいいのでしょうか？

考え方として、どのように考えてＤＢ上の項目定義するべきなのか、ご意見をお願いします。

回答No.4

hn_cthulhu · ベストアンサー

桁数はあくまでも表示の手段であって、実際のデータとは異なる場合がありますので、文字型が良いと思います。
数字は「001」や「000009」と桁数表示できますが、関数で"=[エリア]&[店舗]"と入力した場合、表示形式は無視されます。

例えば[エリア]と[店舗]を同じ３桁表示にし、上記関数での戻り値は
(1)数字としての[エリア]＝"001"、[店舗]="011"は【111】
(2)数字としての[エリア]＝"011"、[店舗]="001"は【111】
(3)固定した文字型として[エリア]＝"001"、[店舗]="011"は【001001】
(4)固定した文字型として[エリア]＝"011"、[店舗]="001"は【011001】

【】の中の数字を見ていただければ(1)と(2)は同じ【111】です。

データ形式を「文字」から「数値」に変換した場合でも、頭の"0"が消されます。
その場合(1)～(4)の戻り値はすべて【111】になります。

多チェーン店舗の場合、「文字」としての「"0"(ゼロ)」を有効にしておかなければ、重複する数値が発生する可能性が極めて高いです。

回答No.5

layy

入力テキストボックス項目の店舗は数字のがユーザ側には扱いやすいです。
コンボボックスならどちらでも良い。
エリアと連結して１フィールド化で扱うケースがあれば
そのときの店舗、エリアは前０付与し固定長の文字のが扱いやすいです。

いずれにしても内部コードが表に出ることは少ないと思います。
（レポートやフォームには店舗名や都道府県名、エリア名で出す方が・・・。）

店舗のマスタテーブルは
店舗－（都道府県）－エリアの３フィールドのコード（と名称）は必要になるでしょう。
また、店舗が決まれば、都道府県やエリアが決まる設計、正規化しましょう。

使いたい場面でどうするかが決まります。
文字型が絶対というわけではありません。

回答No.3

riveron77

> 桁数も固定して変わる可能性が無い場合でも

本当に無いですか？(笑)

私の経験では、コードとかって偉い人達の気まぐれで、結構変わる気がします。
0詰めにしたいとか、アルファベットを入れよう、とか。
この手の作業の大変さ(めんどくささｗ)は、偉い人にはわからんのですｗ

クエリやアプリ側で対応もアリですが、
仕様によってはテーブルのフィールドを変えたくなる場合も。
そういう作業って面倒ですよねぇ。

そういうわけで、コードの類は必ず文字列にしています。
業務に問題なければ、こちらの判断で0詰め。
0詰めなら、画面や帳票のコード項目について、幅も一定になりますし。
(ある程度ですが)

ご参考まで。

回答No.2

mhassy

どのような「項目の型定義」の前に、どのような「コード定義」をすべきかが大前提になると考えます。

ToOrisugaruさんの回答が全てを要約して説明されていらっしゃるため、私の回答はその一部の詳細になってしまうのですが、（その様な回答だと推測しました）。

コード定義をする際に、どのような知識レベルの人々がそのコードを実際に利用するのか？
また、それらのデータを統合して「運用する側のレベル」についてはどうなのか？
等の点を考慮して「コード定義」する必要が有ります。

コードに文字を組み込み、一見して意味が解る（例：Hokkaido01など）様にすると、「コード表」との対比が不要なため、「プルダウンリストを使用しない、用紙での記入運用」も容易になります。
逆に、こういったアナログ的運用が想定されない場合であれば、（入力システムとしてリスト化が可能なので）数値化されている方が、データ（の項目サイズ≒フィールドの容量）として節約が可能ですし、入力者（キーパンチャー）の作業が楽になります（＝数値入力だけの方が作業が容易）。

こういった、現場の実運用レベルを最優先に考慮し、次に、システム的な視点からメンテナンスのしやすさや変更発生時などの「柔軟な対応性」を判断基準にして、「コード」の割り振りを行います。

ここまで綿密に考慮することで、おのずと「コード」に含まれる文字・数字が決まるので、それにあわせた「コードの定義」となります。

御質問に有るような「システム」を構築する側は、どうしても「システムありき」な発想になりがちですが、こういったシステムは「入り口ありき」でデータが発生⇒蓄積⇒利用されるものです。

「発生と蓄積」という、頻度が高く＆精度が要求される部分を、いかに運用し易い設計にするかが、発想の開始点（前提条件）となる・・・と考えます。

次に、システムのメンテその他の「裏方側の事情」を考慮した場合、「エリアのコード」以外についてもいくつかコード化されたデータを同時に扱うと推測します。

この「他のコード」についても同様の配慮の後にコードが決定されるはずです。

こうした複数のコード（表）を扱う場合、Aのコードは数字、Bのコードは文字・・・
システム設計や運用・メンテ側では「データ型の混在」は扱いにくくなり、ToOrisugaruさんの御指摘の通り、バグの原因となりやすいものとなります。

勿論、以上の考え方はDBの規模や、利用・運用される環境次第ではありますが、以上の点を考慮すると「コードは文字型で統一」する方が無難だと、個人的な経験上で考えます。

回答No.1

ToOrisugaru

なるべくその項目属性に適した属性でもつのがベストだと思います。
何故なら、厳密に定義したほうがコンピュータにとって負荷が軽くなるし
他の人がその項目属性を見ただけで、仕様が解りやすいからです。
仕様が解りやすいということは、それだけバグが発生しずらくなります。