データベースの項目名の数値について

Question

例えば,属性1,属性2という項目名を設計するときの命名なんですが、

attr_one,attr_twoと、
attr_1,attr_2どちらがいいですか？

私としては、項目名に数値を入れるのは良くないのかなと思うのですが、どうでしょうか？

ご意見をお待ちしています。

---追記---
属性の名前はテーブルに関連したものにしたいのですが、そのテーブルは色々なカテゴリを包含するテーブルです。(例:車や趣味や仕事)
将来的にカテゴリは増える予定で、カテゴリ別にテーブルを作るのはメンテナンス性が落ちるので、一つのテーブルでまとめるつもりでした。

属性1には車であれば車種、趣味であれば主な趣味、仕事であれば業界など、カテゴリ別で内容が全く変わるので、項目名を汎用的な属性1,2,3とふるように考えました。

また、属性は将来増えていくことも考えているので、
大中小分類よりは数のほうがあとあと楽かと思いました。

このテーブルの使いみちとしては、ある項目にカテゴリコードを持っていて、そのコードでWeb画面での項目の表示を分岐するということにしています。

項目に数値を入れると、例えば17とか18となるとTYPOが発生しやすいかなと思いました(汗

Comments

[iwamoto_takaaki]

テーブルのキーが何で、どのような項目を入れようとしているかを書いてくだされは、具体的なアドバイスができると思います。

[sprite]

railsで開発しているので、テーブルのキーはidです。
項目はあるカテゴリーの属性を入れるのですが、カテゴリーは多岐にわたるので、汎用的な属性名で項目を作成したいです。

[退会済みユーザー]

一般的に「属性名(カラム名)に数値を入れるのは良くない」なんてことは全くないのですが、そう考えられた根拠や経緯は何かありますか？
(例えば、過去のプロジェクトでそういう規約が存在した、あるプログラミング言語のこういう規約の考え方に基づくと駄目なはずだ、…等)

Answer 1

以下の列からなるテーブルに切り出してみてはどうでしょう。

• 主キーとなるid列
• 元のテーブルの主キー
• 属性名または番号
• 属性値

Comments

[hsk]

追記を拝見して、「（会員？顧客？）属性テーブル」なるものを別に切り出して、Key-Value Store に近いテーブルを用意されることを、私もおすすめしたいです。

「(元のテーブルの主キー)さんの(属性名または番号)属性は、(属性値)だ」のような。

[思いつく利点]
・属性の個数の上限を気にしないで済む。
・列を複数もたせる方法だと「属性値10の会員？顧客？をさがす」などのSQL文で
SELECT ... WHERE attr1 = 10 OR attr2 = 10 OR attr3 = 10 ...
と、属性の列数分書かねばならなくなります。

これが、「属性値10かつ20の会員？顧客？をさがす」となれば、ちょっとSQLがにわかに思いつきません（副問い合わせで、結局「（会員？顧客？）属性テーブル」みたいなものを切り出すかな、私なら）。

別テーブルにしておけば、EXISTS句を使ったり、もしくは
SELECT 会員ID, COUNT(*) FROM 別テーブル WHERE 属性値 IN (10,20) GROUP BY 会員ID HAVING COUNT(*)=2
と書いたりも（会員ID&属性値で、重複登録がなければ）、技能の高い方ならばもっとスマートにも書けます。

[sprite]

ありがとうございます。
コチラの方法を撮りたいと思います。

Answer 2

1,2 でも英語でもなくて、その項目の目的や用途を表現できる分かり易いネーミングを考えては？

わたしは設計や開発をするのがメインですが、自分が設計したテーブルでもプログラムでも、あとでメンテするであろう人がプログラムを変更する際に分かり易いネーミングをするのが最低限のモラルだと考えて設計しています。

Answer 3

＞項目名に数値を入れるのは良くないのかな
と思われる理由は、どのあたりでしょうか（DBの保守管理上、DBへアクセスするプログラムへの支障、そのほか）？

指定する属性の数が有限個であり、（順序のナンバリング以外には）互いに全く同列の意味合いであるなら、（英単語でつけるくらいならば）私ならむしろ数字を列名にサフィックスとして使用しますね。attr_one,attr_two,attr_three なら attr_A,attr_B,attr_C のほうがまだ好みです（互いに同等なことがぱっと推測しやすい）。

が、追加情報から推測するに、テーブルの正規化設計をまず検討してみてはいかがでしょう？第1正規形（繰返し項目の排除）に。
（もしMySQLでしたら、SET型なる機能もありますね。属性の種類（とりうる値）が固定でしたら、列をひとつにしてしまってこちらを利用することも有用でしょう）

列それぞれに固有の異なる意味があるならば、Orlofskyさんの仰るように、頭をしぼってその意味を列名に盛り込みます。

Answer 4

文字の問題でなく、カラム名に番号をつけたいと思ったら設計が足りないと考えてください。
繰り返し項目は別テーブルで管理するというのが、一般的なテーブル設計の作法です。

この繰り返し項目を排除する方法を第一正規化と呼びます。
興味があれば調べてみてください。

なぜ、繰り返し項目を避けるかというと、運用を続けると扱う項目が増えていきそのたびにプログラムを更新し続けることになるためです。

これを避けるためには、この項目は別のテーブルで管理する方法です。項目の種別ごとにテーブルを設ける方法があります。spriteさんがおっしゃるように、どんどん追加される項目にＤＢを合わせていくのは手間がかかるかもしれません。

ここで、なぜＤＢではテーブルの定義をするかを考えてみましょう。登録するデータ形式を揃えて項目を縦に並べることで検索したり集計したりするためではないでしょうか。

ここで質問です。
今回の項目で検索する必要がありますか？

テーブルのキーやほかの項目で検索して、値を利用すると思います。
ここで、将来検索が必要かもしれないという意見があると思います。
経験的に言えますが、これらの項目を検索する必要がある際に番号付きの項目を検索するときには全件検索を行うことになります。

じつは、テーブルを使うＤＢはデータ形式がはっきりしないデータを扱うのが苦手です。この問題を解決するためにいくつかのＤＢでは、スキーマに自由度があるxmlやjson形式の項目をサポートするＤＢが増えてきました。spriteさんがご利用予定のＤＢがxmlの形式を利用可能かわかりませんが、非固定長の文字列利用されてはどうでしょうか。

つまり、カテゴリ種別と値（ＸＭＬなど）の組み合わせ項目にすることをお勧めします。

Answer 5

私としては、項目名に数値を入れるのは良くないのかなと思うのですが、どうでしょうか？

そう思う理由がよく判りませんが、項目名に数字を使うことはよくあります。それに、だからといって数字を英語に置き換えるというのは本質的には何も変えていないような気がします。

例えば、あるアプリケーションの入力欄が、「メールアドレス1」「メールアドレス2」のようになっていたら、項目名も「email_addr1」「email_addr2」のようにするのが自然です。
「属性1」「属性2」もそれだけでは何のことだか判りませんが、システムとしてその名前を使っているのなら、そのまま項目名にした方がむしろ判りやすいです。

---

追記
追記の内容を見ましたが、どうも状況が違ったようですね。

そのテーブルは色々なカテゴリを包含するテーブルです。(例:車や趣味や仕事)

この時点で何か違うような気がするのですが。

将来的にカテゴリは増える予定で、カテゴリ別にテーブルを作るのはメンテナンス性が落ちるので、

なぜそう考えるのか、やはりいまいち判りません。異なる性質のものを一緒くたに扱って混乱する方がメンテナンス性が落ちると思うのですが。

カテゴリ別で内容が全く変わるので、

全く違う内容のものに同じ名前を付けたら混乱すること必至です。

また、属性は将来増えていくことも考えているので、
大中小分類よりは数のほうがあとあと楽かと思いました。

例えば「車」の属性が増えたら、自動的に「仕事」の属性も増えるということになりますが、増えた属性をどう扱えばいいのでしょうか。車は属性1～5を使って、仕事は属性1～3、というように決めておくのでしょうか。
あるいは、「仕事」で勤続年数のような項目を作りたいけど、数値型にするとほかのカテゴリで使えないから文字列型にしておこう、ということにはならないでしょうか。

このテーブルの使いみちとしては、ある項目にカテゴリコードを持っていて、そのコードでWeb画面での項目の表示を分岐するということにしています。

結局分岐するのであれば、カテゴリ別にテーブルを設計した方が直感的で判りやすいと思います。

Answer 6

アンダースコアを区切り文字として、ハイフンを区切り文字として、キャメルケース文字列に変換してjavaのエンティティやビーンに自動的にdb取得結果を格納する仕組みがあったりします。数字の前にアンダースコアがあると可逆変換できなくなる、変換ルールが曖昧になるのでdbのカラム名にはなるべく避けたいところです。
attrOne が、javaで、ロワーキャメルケース、AttrOne がc#やvbでお馴染みのアッパーキャメルケース、です。dbのカラム名は、長ければ良いものでも無いし、短いほど動作が速くなる時代はとうに過ぎ去っています。ナガタイヲアラワス が表現できれば良いと思います。数字を入れることに異議はありません。が、数字の前にアンダースコアやハイフンを入れるのはなるべく避けたいところです。開発言語次第ですけど。

x.getAttrOne();
は、
class Xbean {
private String attrOne;
public getAttrOne() ...
}
で、xtable の attr_one カラムと名前の相互変換が可能になり、dbへの設定、取得処理を自動化できます。