C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

表示順フィールドのデータ型

掲示板トップ C# と VB.NET 入門 新規作成 利用方法/規約 ツリー表示 トピック表示 ランキング 記事検索 過去ログ

[トピック内 4 記事 (1 - 4 表示)]　 << 0 >>

■102719 / inTopicNo.1) 　表示順フィールドのデータ型
  ▼■
□投稿者/ eb (11回)-(2023/12/13(Wed) 17:47:06)

分類:[データベース全般]　

2023/12/13(Wed) 17:48:11 編集(投稿者)

最近 Access 関連の本を読んでいたら、
コンボボックスに使うマスタには表示順フィールドを設けると便利だという話題があり、
こういうアドバイスがされていました。
「テキスト型（シフトJIS順での並び替えが設定可能）で設定しておくと、
　ほかの開発言語やデータベースのシステムと並行して使う場合に、うまく並べ替えを行えます。
　システムによっては、例えば100までの連番があった場合、
　「1」の次が「10」になってしまう場合があるからです」
そして、その値に "010", "020", "030", "040", "050", … と入力してある図が掲載されていました。

個人的にはただ数値型で良いと思っていたので驚き、
検索したところ数値型にしている情報ばかりを見つけましたが、
「ほかの開発言語やデータベースのシステム」の例は何がありそうでしょうか。
実際テキスト型を使うのが良さそうでしょうか。
引用返信 編集キー/
■102720 / inTopicNo.2) 　Re[1]: 表示順フィールドのデータ型
▲▼■
□投稿者/ 魔界の仮面弁士 (3744回)-(2023/12/13(Wed) 19:58:39)
2023/12/13(Wed) 20:01:35 編集(投稿者)

■No102719 (eb さん) に返信
> コンボボックスに使うマスタには表示順フィールドを設けると便利だという話題があり、
たとえば、駅名を指定するリストがあったとして、そこに新駅が追加された場合、
新駅を最後にするのではなく、路線の駅順に合わせてリストの途中に挿入したいことがあるでしょう。
そのような場合、ソート用の項目が別に用意されていると、表示する際に都合が良かったりしますね。


> 「テキスト型（シフトJIS順での並び替えが設定可能）で設定しておくと
（ここでいう「シフトJIS順」というのは、Access における照合順序設定のことかな…）


> 実際テキスト型を使うのが良さそうでしょうか。
どうでしょうね。個人的にはその時々の条件に応じて決まるんじゃないかな、と思います。
数値で管理されている ID や CODE の場合、数値型にするか文字列型にするかは処理系次第かと。

データ量としては、数値型の方が容量を抑えられますので、数値型で困らないなら数値のまま扱っても良いでしょう。

一方、各行の文字数を一定にした固定長データを用意したい場合は、
あえてゼロパディングした文字列型が採用されたりもします。

たとえば ODBC 連携の場合、「電話番号が数値型になっては困る」などの事情もあって、
すべてのフィールドが文字列型という前提でデータ交換する設計になっているケースを見かけます。

例示されたように "1" → "10" → "2" というソート順になってしまうと困る場合は、
最初から "001" 、"002" といった書式が採用されることはあるでしょうね。


今後、アルファベットを含む可能性がゼロではないという理由によって、
最初から文字列型で管理しておくといったケースも見たことがあります。
さらにそれが固定長の場合は 可変長テキスト型ではなく固定長テキストが使われるケースも目にします。
金融機関コードとか市区町村コードとかは固定長ですね。(処理系によっては数値で扱われることもある)

あとはチェックデジットの有無で決まることもしばしば。
たとえば市区町村コードの場合、末尾のチェックデジットを含めるかどうかで
5 桁系だったり 6 桁系だったりかが変化するので、先頭ゼロを維持した方が都合が良いことも。

これらの話は、そのシステム単体におけるデータ保持というよりは、他システムとの連携性という意味合いが強いので、質問内容の本題からは外れているかもしれません。


別の話では、日付があえて文字列型で処理されているケースも見かけますね。年/月/日を別々の数値型で管理する実装もまれにあります。
(たとえば墓管理や家系図管理における生没年月日情報では、年月はわかるが日が不明とか、年が不明で月日だけ判明しているといったケースがある)
引用返信 編集キー/
■102721 / inTopicNo.3) 　Re[1]: 表示順フィールドのデータ型
▲▼■
□投稿者/ くま (14回)-(2023/12/13(Wed) 20:11:38)
ずいぶんと懐かしい話だな...
もともとCOBOLとかで使用された汎用機におけるデータベース
(PCとか存在する前ね)
SQLなんかも使用できなかった頃、データ保存容量がとても少ないころがありました。

その頃文字に格納できる一般的な「0-9A-Z」を1バイトで表現できたので数値より効率が良かったんです。
あと今だと大体Format関数なんかですぐ数値から文字列へ変換できるけど昔は無かったからね
数値から文字コード変換して文字列へ変換なんて関数用意したりしていました。

・ちょっと脱線...
その関係でデータを確認する際、数値を文字化する関数を通す必要がありそうすると処理が遅くってとてもデバックできませんでした。
汎用機(現在でいわれるサーバ)で50行のCOBOLをコンパイルするのに4時間以上待って、1文字でも間違っているとコンパイルエラー
端末(PCではない)でコピペとかできないので間違えないように手打ちしないといけないし
実行待ちでさらに2時間、結果をプリンタで印刷するのに1時間で手元に届くまで丸1日以上...
結局人が多いと待ちになるので、徹夜や休日出勤が当たり前の世界でしたからね...


あとコードを組み合わせて意味を持たせたりもしていましたね。
(例として郵便番号"160-0021"の場合、"160"が「東京都新宿区」を表し"0021"が「歌舞伎町」を表す。)
あと本に使われている
・JANコード
なんかも各桁に意味があったりします

その様な組み合わせ等考えると文字の方が扱いやすかったというのが、数値ではなく文字列で使用されていた理由です。
大体コード表みたいのがデータベース上存在していて、そこを参照することで値を取得していたりしました。

この辺は例として
" ":"未登録"
"1":"男性"
"2":"女性"
"Z":"不明"
として男女別に並べ替えるとかで使用されてました

あとは
" ":"未登録"
"1":"はい"
"2":"いいえ"
とか...

あとは商品番号管理で"01-10-222-3333-0"
大分類:"01"
中分類:"10"
小分類:"222"
商品番号:"3333"
管理番号:"0"
なんらかの理由で商品がリニューアルすると管理番号が1足されて
"01-10-222-3333-1", "01-10-222-3333-2"
(商品としては同じ部品だがリニューアルがかかっている)
絶版になった場合、管理番号が"Z"になって
"01-10-222-3333-Z"
とかにしておけば、その商品が絶版なのが検索しなくてもわかるようにしておくとか
ですかね...。
この場合項目に「商品番号」として1つ文字列16桁用意すればよいが
数値だと5項目用意して表示する際format関数使ったりして整形しないといけないですね...
(VBAのLong型だと最大数値2147483647なので12桁入らない...)

そういうシステムが元になっていたりするとコード形態が引き継がれて、「文字列で使った方が良い」という話になったりします。
さらに新規だとコード化もされなくって、文字列で"はい","いいえ"とか格納するような設計もありますね。
(並び順に使わない項目ならリレーション貼らないで値が分かりますから...。)

ただコード化すると対応する表がないと意味が分かりません。その為データ保持ということでコード形態を残されている所も多いみたいです。
※今のDBだと暗号化で対応できちゃいますが...

まとめると
・昔はデータ量圧縮の為なんでも文字コード化して圧縮していた。
その為西暦の"1999"年の上2桁を切って"99"保存していたため、2000年問題ということがおきた
・その2000年問題対応に関連して新しいDBやSQL言語の普及なので数字を数値として保存する方向へ変化
・さらに大容量高速度のデータ格納にも対応できるだけの記録媒体の登場により文字コード化が減少していった
・しかし分類をコードだけで判断できたり、難読化の利点もあるので一部項目に関しては「文字コード化」の項目が残る
こんな感じです。
引用返信 編集キー/
■102722 / inTopicNo.4) 　Re[2]: 表示順フィールドのデータ型
▲▼■
□投稿者/ eb (12回)-(2023/12/14(Thu) 05:38:13)
ありがとうございます。
大ベテランのお二方のお話非常に興味深いです。

>>魔界の仮面弁士様

>> 「テキスト型（シフトJIS順での並び替えが設定可能）で設定しておくと
>（ここでいう「シフトJIS順」というのは、Access における照合順序設定のことかな…）

私はよく分かっていませんが（苦笑）、そうだと思われます。
No.1 の投稿後検索して、私は伝え聞くだけですが、
どうも COBOL 時代は並べ替えが非常に大変だったそうで
（くま様も「変換も自前だった」と書いて下さいましたが）、、
そのへんから著者が「Access は並べ替えてくれるよ！　シフト JIS 順だよ！」
と言いたかっただけのかもしれないと想像しました。

いろいろな事例のお話も参考になります。

>これらの話は、そのシステム単体におけるデータ保持というよりは、他システムとの連携性という意味合いが強いので、質問内容の本題からは外れているかもしれません。

いえいえ、こういう情報が伺いたかったので
他の Access 掲示板ではなくあえてこちらに投稿させていただいた次第です。
著者がわざわざアドバイスした背景を知りたかったのです。


>>くま様

>ずいぶんと懐かしい話だな...

どうも VBA は VB6.0 とのこと、DAO も ADO も化石、
Access は 2000 の頃から進歩があまり無い（？）らしく、
Access に詳しい方が比較的最近推薦していた 2006 年頃世に出た本を読んで
今回「懐かしい」と言われる質問になった次第です。

>あと今だと大体Format関数なんかですぐ数値から文字列へ変換できるけど昔は無かったからね
上でちょっと書きましたが、並べ替えも自前だったってことでいいでしょうか。
情報処理技術者試験でやらされたのを思い出しますが、
これはマニュアル車免許を取ったような感じですね。

>・ちょっと脱線...
のんびりできるのかできないのかよく分からない雰囲気です（苦笑）
1990年代前半に出た本にエンジニアの健康不良や「成田離婚」の話が載ってましたが、
ブラックっぽいのはなかなか変わらないのですね。

「まとめ」もありがとうございます。
大変勉強になりました。



仕事・勉強用のメモに張り付けさせていただきます。
ありがとうございました。
解決済み
引用返信 編集キー/

このトピックをツリーで一括表示


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

このトピックに書きこむ