データベースのフィールドのデータ型について

このQ&Aのポイント
  • データベースのフィールドのデータ型を考える際に、文字列の桁エラーを避けるために適切なデータ型を選択する必要があります。
  • ユーザーIDなどの固定長の文字列は、VARCHARよりもCHAR型を使用することで桁エラーを防ぐことができます。
  • データベースの種類によってもデータ型の選択に違いがありますので、使用しているデータベースに合わせて適切なデータ型を選ぶ必要があります。
回答を見る
  • ベストアンサー

データベースのフィールドのデータ型について

くだらない質問で申し訳ありませんが宜しくお願いします。 下記のようなデータを格納するテーブルを構築しています。 ・ユーザーID ・名前 ・カタカナ ・パスワード ・年齢 ・郵便番号 ・住所1 ・住所2 ・住所3 ・電話番号 ・メールアドレス ・備考 ・削除フラグ ・登録者 ・登録日 ・更新者 ・更新日 上記の内容を下記のようなテーブルのフィールドのデータ型を考えました。 ・ユーザーIDのデータ型をVARCHAR(4) ・名前のデータ型をVARCHAR(32) ・カタカナのデータ型をVARCHAR(32) ・パスワードのデータ型をVARCHAR(255) ・年齢のデータ型をINTEGER ・郵便番号のデータ型をVARCHAR(8) ・住所1のデータ型をVARCHAR(255) ・住所2のデータ型をVARCHAR(255) ・住所3のデータ型をVARCHAR(255) ・電話番号のデータ型をVARCHAR(18) ・メールアドレスのデータ型をVARCHAR(255) ・備考のデータ型をTEXT ・削除フラグのデータ型をVARCHAR(1) ・登録者のデータ型をVARCHAR(4) ・登録日のデータ型をTIMESTAMP ・更新者のデータ型をVARCHAR(4) ・更新日のデータ型をTIMESTAMP そうしたら下記のような風にテーブルのフィールドのデータ型にしたら格納する文字列の桁エラーが起こらないからどうといわれました。 ・ユーザーIDのデータ型をVARCHAR(4) ・名前のデータ型をTEXT ・カタカナのデータ型をTEXT ・パスワードのデータ型をTEXT ・年齢のデータ型をTEXT ・郵便番号のデータ型をTEXT ・住所1のデータ型をTEXT ・住所2のデータ型をTEXT ・住所3のデータ型をTEXT ・電話番号のデータ型をTEXT ・メールアドレスのデータ型をTEXT ・備考のデータ型をTEXT ・削除フラグのデータ型をVARCHAR(1) ・登録者のデータ型をVARCHAR(4) ・登録日のデータ型をTIMESTAMP ・更新者のデータ型をVARCHAR(4) ・更新日のデータ型をTIMESTAMP ※現在、使用しているデータベースはPostgreSQLですが、Microsoft SQL ServerやOracleやMySQL等の他のデータベースでもいいものなのかもご教授いただけると助かります。 私の知識不足でどちらがいいのかがわからず投稿させてもらいました。 申し訳ありませんが皆さんのお知恵をお貸し下さい。 宜しくお願いします。

質問者が選んだベストアンサー

  • ベストアンサー
  • t_ohta
  • ベストアンサー率38% (5081/13278)
回答No.3

> 文字列を格納するフィールド型は可変長文字列型にした方がいいのか、固定長文字列型にした方がいいのかです。 varchar 型も可変長文字列なので varchar と text を比べても意味はありません。 固定長と可変長を比べるなら char と varchar を比べなければ行けません。 CPUの性能が良くなり、メモリの搭載量が増え、HDDの読込速度が上がった今となっては、char 型の優位性はあまりないと考えていいでしょう。 データの取扱量が多い環境では、char より varchar の方が資源の有効利用という意味ではメリットが多いかもしれません。 text 型はRDBMSによっては検索時の性能や制限に差があるので、必要最小限にするべきだと思います。 よほど大きな文字列が入る予定が無ければ、varchar(2000) といった感じで varchar 型で大きく取った方が使い勝手がいい場合があります。

その他の回答 (2)

  • kmee
  • ベストアンサー率55% (1857/3366)
回答No.2

varcharは「可変長文字列」ですよ。 PostgreSQLでは、こんなのがありました。 http://lets.postgresql.jp/documents/technical/text-processing/1 これに従えば、textが有効的なのは「備考」くらいでしょう。 長いと有名なピカソの本名でも200文字までいきません。 MySQLでは、varcharに比べてtextには制限があります http://dev.mysql.com/doc/refman/5.1/ja/blob.html MS SQL Serverでは、textは「将来削除される予定」とあります http://msdn.microsoft.com/ja-jp/library/ms187993.aspx

  • t_ohta
  • ベストアンサー率38% (5081/13278)
回答No.1

Oracleも視野に入れるなら TEXT 型は不適切です。 Oracleには TEXT 型がありませんので、そのままのDDLではテーブルを作成できませんし、PostgreSQLからデータをコンバートしようとした時、長い文字列が入っているとコンバートできない可能性が有ります。 また、検索をかける際も VARCHAR 型なら文字の正規化をDBにやらせてあいまい検索できる等のメリットがあります。(RDBMSによっては TEXT 型でも対応できる場合もありますが全てではありません) TEXT 型は文字長を気にしなくて済むので便利ですが、使い勝手が悪い場合もありますし、郵便番号のように桁数が決まっているようなものの場合、不正なデータが入ってしまう可能性を残してしまいますので、どうしても必要な場合だけにとどめた方がいいと思います。

wakaba1972
質問者

補足

回答ありがとうございます。 説明不足ですみません。簡単に説明をさせていただきます。 文字列を格納するフィールド型は可変長文字列型にした方がいいのか、固定長文字列型にした方がいいのかです。 ネットで調べてみましたがいい回答を見つける事ができませんでした。 ※たぶん、私の探し方が下手なんだと思いますが・・・ 大変申し訳ありませんが再度、説明していただけませんでしょうか。 宜しくお願いします。

関連するQ&A

  • 特定のフィールドが更新されたときだけ日時を更新する

    targetのデータが変わった・更新されたときに、update_dayをその日時に更新したいと考えています。 フィールドは、field_1, field_2, target, field_4, field_5, update_day, new_day ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー field_1=int型、primary key field_2=varchar型、 target=float型(7.3) field_4=boolean型 field_5=text型 update_day=timestamp型、NULL、 default CURRENT_TIMESTAMP、 on update CURRENT_TIMESTAMP new_day=timestamp型、NOT NULL、 default '0000-00-00 00:00:00' ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー target以外のフィールドのデータが更新されたときにもupdate_dayが更新されてしまいます。 ■field_1, field_2, field_4, field_5 ■target, update_day, new_day とテーブルを分けるしか方法がありませんか??? ぐっちゃりしてしまうため極力テーブルを分けたくありません。

    • ベストアンサー
    • PHP
  • Filemakerにおけるフィールドの考え方

    Filemaker9(以下FM)を使用してシステムを作ることになりました。 FMのフィールドの考え方について教えてください。 以前は主にACCESSを使用して作成していましたが、フィールドには データの保管や加工が出来る[連結フィールド]とフィールド同士をつなげて表示したり、関数を使用して任意の文字を取り出したりする [非連結フィールド]がありました。 FMをいじり始めたのですが、[住所1][住所2]フィールドを連結して 表示したい場合は[住所結合]のような計算フィールドをテーブルの中に 別途作成して表示するとのことです。 考え方としてはわかるのですが、そうなるとレイアウト毎に表示方法が 違う場合や郵便番号を一桁ずつ分ける場合などは、 [郵便番号] [住所1] [住所2] [住所3] [連結住所A] → [住所1]&[住所2] 'フォームAのみで使う [連結住所B] → [住所1]&[住所2]&[住所3] 'フォームBのみで使う [郵便番号1] → Left([郵便番号],1) 郵便番号を一桁ずつに分ける↓ [郵便番号2] → Middle([郵便番号],2,1) [郵便番号3] → Middle([郵便番号],3,1) [郵便番号4] → Middle([郵便番号],5,1) [郵便番号5] → Middle([郵便番号],6,1) [郵便番号6] → Middle([郵便番号],7,1) [郵便番号7] → Right([郵便番号],1) 上記のようにテーブル内に13フィールド必要と言うことでしょうか? テーブル内にフィールドを作らない方法はないものでしょうか? とりかかりでちょっと躓いていてしまいました。 どうかよろしくお願いいたします。

  • アクセス(access2003)で郵便番号を入力して住所録作成(カタカナ表示)

    いつもお世話になっております。 アクセス2003で住所録をカタカナ表記で作成することになったのですが、行き詰ってしまったのでここで質問いたしました。 元のデータとなる郵便番号とカタカナ表記の住所は 日本郵便からデータをダウンロード(CSV)して、 テーブルにインポートするところまではできています。 しかし、特定の郵便番号を入力して、該当する住所を呼び出して 住所録としてテーブルを作ることができません。 郵便番号とカタカナの住所が表示されるだけでいいのですが・・・ フォームというのを使うのでしょうか? 住所が漢字表記なら、住所入力支援を使えば良いことは わかっているのですが、カタカナでの表記なので困っています。 取るに足らない質問かもしれませんが、 ご回答いただければ幸いです。 どうぞよろしくお願いします。

  • データベース設計

    データベースを使ったサイトを勉強しています。 始めにデータベースを作ろうと思って早速壁に当たりました。 必要なデータは 「ID,フラグ1,フラグ2,名前,住所,TEL,登録日,年代,趣味,メモ」。 IDは一意な番号、 フラグ1,フラグ2はYes/No、 年代は10個程度の決められた文字の中から1個、 趣味は10種類程度の決められた文字の中から複数。 このようなデータが入ったデータベースを作りたい場合、どのような構造にするのが良いのでしょうか。 アドバイス頂けたらと思います。

    • ベストアンサー
    • MySQL
  • access table 上書きしてデータ追VBA

    access365 名簿accdbにおいて テーブル1に ID 名前 住所 郵便番号 という項目があり IDは重複不可 数値 テーブル2に ID 名前 住所 郵便番号 という項目があり IDは重複不可 数値 と ふたつのテーブルがあるとき 追加クエリーで テーブル1に テーブル2のデータを追加するときは 同一のIDでは 上書きができません テーブル2のIDが テーブル1にまだ存在しないIDの数値であれば 追加クエリーにより データの追加ができますが 例えばIDが3の人物がいて そのテーブル1の住所が東京で これが新しいデータの格納されているテーブル2では ID3の住所が千葉となったときに これを追加クエリーでIDを3として上書きはできない構造のようです 更新クエリー というのも調べてみましたが ある一定の規則でたとえば物品の値段が100円増しのような 一定の更新条件がある場合であれば更新クエリーが使えますが 上の例のようにテーブル2においてテーブル1にもすでに名前の登録のあるIDのひとの 数人が住所がテーブル2において 新しいものとして変更されていて それをテーブル1に一括で住所の変更のできるVBA 御教示いただけますか (上記の場合ですと住所の変更と郵便番号の変換が同時に当然起きえます) また 同時に テーブル1にはIDの登録もまだない新規IDのひとも テーブル2に存在するとします 要は テーブル2には テーブル1にすでにID人物登録のあるひとと 新規IDのひとが混在している条件で、作りたいと思います すみませんが、おちから頂けると助かります 宜しくお願い致します office365 win10

  • Access2003:重複なしでデータを取り出す方法を教えてください

    住所テーブルと注文テーブルを結合させ、ダブらない抽出をしたいと思っています。 (最終的には「最近の注文した顧客の住所ラベル」を作りたいのです) 住所テーブルは ID(オートナンバー型)|*顧客番号(テキスト型)|住所(テキスト型)|郵便番号(テキスト型)  *は主キー 注文テーブルは *注文ID(オートナンバー型)|顧客番号(テキスト型)|注文日(Date型)|商品ID(テキスト型)|注文数(Int型)  *は主キー 注文テーブルの注文日を2007/1/1以降とクエリをかけると、同じ顧客番号が出ます。 つまり、注文日を2007/1/1以降とした住所テーブルと顧客テーブルを結合してクエリをかけると、注文テーブルで重複した顧客のデータも出てしまいます。 これを同じ顧客番号が重複しないように抽出したいのです。 他のQAも拝見しましたが、イマイチ行いたい事柄にヒットしていないと思い、 更には当方がそれらを理解する域まで及ばないと思いまして、新しい質問としてあげさせていただきました。 どなた様か、お分かりの方がおいででしたらご教示くださいますよう、お願い申し上げます。

  • テーブルに郵便番号フィールドを設けたいのですが

    アクセスで、テーブルに郵便番号フィールドを設けたいのですが どういう書式設定にすればいいか悩んでいます。 フィールド名:郵便番号 データ型:テキスト型 にしました。 フィールドの書式の設定は何もしていません。 実際の郵便番号は 123-4567 です。 実際データとして郵便番号を入れる時は 1234567 と入れた方が良いのか 123-4567 といれたほうがいいのか どちらでしょうか? 細かいこと気にし過ぎですいません・・・

  • 住所入力支援について(Access2000)

    Access2000を使用しています。テーブルのフィールドプロパティで郵便番号、住所のところで住所入力支援とありますが、この郵便番号データはいつのものが入っているのでしょうか?最新データには更新されないんですよね。多分・・・

  • 複数のフィールドを比較してデータが更新されているフィールド名を抽出したい!

    素人質問で申し訳ありませんが教えてください。実は或る伝票管理テーブルがあり、そのリスト中の実質的なキーコードである「伝票番号」フィールドには重複可能なインデックスを設定してあります。それとは別に主キーを設定してはいますが、それはオートナンバーとしてデータをソートするくらいにしか使っていません。 この伝票管理テーブルは外部のTXTファイルを一括して取り込む受け皿として存在していて、アクセス上で各フィールドにキー入力することはありません。 このように「伝票番号」フィールドには同じ番号のものが複数存在するのですが、同じ番号の中で一番最初のものが新規に登録されたもので、2番目以降にくるものが変更として登録されたものですが、残念ながらどのフィールドが更新されたのか判らないので、その都度一項目ずつマニュアルでチェックしている為にとても時間が掛かっています。 それぞれのデータには「伝票番号」以外に合計10項目くらいのフィールドが存在しています。 アクセスで何とか処理できないものかと思いあぐねている内容としては、同じ「伝票番号」をもつデータを時系列的に2データずつ比較します。(直近データ同士の比較) その上で、 (1)10項目のフィールド全てのデータが両者で全くイコールならば、新しい方の行を削除する。 (2)いずれかのフィールドのデータが更新されていれば、主キー同士の番号と更新されているフィールド名を抽出して、別のテーブルにその結果を放り投げる。 例えば、『800888』という「伝票番号」をもったデータが4個テーブル中に存在していて、それぞれに10、25、40、80という主キーが付番されているとして、 (1) 25は10に対し、フィールドKとNのデータが更新されている。 (2) 40は25と全てのデータが全く同じ。 (3) 80は40(=25)とフィールドDとPのデータが違う。 となった場合、まず伝票管理テーブルから主キー40の行を削除し、その上で下記のようなデータを抽出できればうれしいのですが。 10/25: K N 25/80: D P 雲を掴むような話で申し訳ありませんが、こんなことが可能なのかどうかご教示頂ければ幸甚です。宜しくお願いします。

  • 複数のテーブルから登録順にデータ取得

    複数のテーブルから登録順にデータ取得なんてことできるのでしょうか? table_A A_id int A_time timestamp A_title text table_B B_id int B_time timestamp B_title text とtable_A table_Bにデータが存在するときに AB関係なく A_titleもしくはB_title を登録順のA_timeもしくはB_time 順に10個とかSQL一発でかけるのでしょうか? そもそもこのような作りにするな!ということでしょうが・・・