dポイントプレゼントキャンペーン実施中!

テーブルの設計はとりあえず文字列で取り込み?

こんにちは。会社の上司にSQLについて教えてもらいました(ACCESS2003)。
上司曰く、とりあえずテーブルの設計はvarcharにしておけば大丈夫。
もし取り込んだ値が数値なら、あとで数値に変換する関数で数値に変換して計算行えばいいよと言われました。

とりあえず、文字列なら必ずインポートできるからテーブルのデータ型は全て文字列型。
というのは正しいのでしょうか?様々な型があるのに、すべて文字列型にしてもいいのかなと素朴な疑問が生まれました。

よろしくお願いします。

A 回答 (4件)

>varcharにしておけば大丈夫


それはフィールドのデータ型の話ですね。
業務にマッチしたテーブル設計とは次元が
違います。
>文字列なら必ずインポートできるから
インポートするとは即ち、そういうテーブルが
新しくできると言うことなので、「設計する」
という話ではなくなります。

確かに、何も考えないでインポートすると、
勝手に型が決まってしまうので、会員IDの
ように前ゼロが意味を持つデータなのに、
数値と認識されて前ゼロが取れるという
トラブルが起きないとも限りません。
なので、インポート時の問合せには全て
文字型と答えておけと言うのかも知れない
ですね。
でも、それは技術云々ではなく、業務上の
要件ですから、知らなくてよいというもの
でもないと思いますよ。

少なくとも、数値、文字列、日付くらいは区別
して使うべきでしょうね。いずれは使いこなせる
ようにならないと、アナタが困りますよ。
    • good
    • 0
この回答へのお礼

ありがとうございました!!

お礼日時:2011/02/11 00:19

補足




インポートとかエクスポート、ファイル転送等外部とのやりとりは自分らのシステムだけでなく相手がいますから、連携の確立はけっこう重要です。

とりあえずデータ受け取れば何とかなる。インポートは失敗できないし何かあっても修正しないで済む方がうれしい。そういう意味も含まれているはず。
    • good
    • 0
この回答へのお礼

ありがとうございました!!

お礼日時:2011/02/11 00:19

> 上司曰く、とりあえずテーブルの設計はvarcharにしておけば大丈夫。


データ規模が小さいうちはいいですけどね。
データ量が大きくなると、数値は数値型、日付は日付型で持っておいたほうがDBも小さくなりますし、クエリの際の演算コストも少なくてすみます。
なんにせよ、どこかのタイミングではデータを正しくしなければならないですから、インポートの前か後かはどちらでも。本番用のテーブルは型分けて使用することをお勧めします。
    • good
    • 0
この回答へのお礼

ありがとうございました!!

お礼日時:2011/02/11 00:19

型指定すると、読み込み時点でエラーする可能性があります。



読み込み時点のエラーは低レベルなエラーなので、読み込みエラーをさせるとシステム全体が止まってしまいますが、読み込んでからの後処理なら、その手のエラーは止めずに続行させるようプログラミングすることが可能です。どっちが良いかはシステムの考え方に依存しますので、どっちが正しいとは言えません。

まあ、手慣れたプログラマなら、まず文字列で持ち込んでから判断させる方がラクなんですけどね・・・。
    • good
    • 0
この回答へのお礼

ありがとうございました!!

お礼日時:2011/02/11 00:19

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

関連するカテゴリからQ&Aを探す