| ■102721 / 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言語の普及なので数字を数値として保存する方向へ変化
・さらに大容量高速度のデータ格納にも対応できるだけの記録媒体の登場により文字コード化が減少していった
・しかし分類をコードだけで判断できたり、難読化の利点もあるので一部項目に関しては「文字コード化」の項目が残る
こんな感じです。
|
|
表示順フィールドのデータ型
/ eb (23/12/13(Wed) 17:47) #102719 
上記ツリーを一括表示 / 上記ツリーをトピック表示
