テーマ、知りたいこと
PHP, MysqlでWebシステムを作成しています。
データベース設計時にカラムIDを「c + テーブル番号 + 連番」と定義しています。
例えばテーブルID「t0001」に対して「c0001001, c0001002...」としています。
この設計は避けるべきでしょうか？
背景、状況
ExcelでカラムIDの対応表を別途用意しており、これを見ながら作業をしています。
おそらく「避けるべき」とする回答が多いと思いますので、私の考えるメリットを挙げます。
・テーブルの結合時にカラムIDが競合しない
・カラムID単体でテーブルIDが割り出せる
・テキスト検索で利用箇所の特定が容易
・固定長なのでコードが整理しやすい（何となくですが...）
皆さんの意見をお聞きしたいです。
よろしくお願い致します。
追記
逆に「id, name...」のような構成にあまりメリットを感じていません。
一番は可読性ですが、対応表で十分に感じています。
もし連番ではない命名方法にすべき理由があれば教えていただきたいです！
よろしくお願いします。
追記_2
想像以上に厳しい意見が多く、勉強不足を痛感しております。
複数人開発の経験がなく、オレオレなフレームワークで独自路線を貫いてきましたが、しっかり勉強して出直してきます。
回答いただいた皆様ありがとうございました。
回答16件
#1
総合スコア117571
投稿2025/03/25 06:17
ご提示のメリットに魅力を感じないので「避けるべき」という回答しか導けませんが、実は私も同様の構成で運用しているテーブルがあります。
目的はCSVデータを一旦保管するテーブルで、すべてのカラムの型はTEXTにしてあります。そこから運用テーブルにデータの流し込みをするにはちょうどよい感じになっています。なので絶対だめかと言われると時と場合と運用方法によるとしかいい難いです。
#2
総合スコア843
投稿2025/03/25 07:07
はい、避けるべきです
今日では実行環境に十分なリソースがあることが多く、
可読性やメンテナンス性を犠牲にして良しとするケースはほとんどありません。
typoして1文字間違えるだけで全然違うテーブルのカラムを指すなんて恐怖でしかないかと思います。
逆に「id, name...」のような構成にあまりメリットを感じていません。
てきとうなSQLですが比較のために両方書いてみました
sql
1SELECT 2 t0001.c0001001, 3 t0001.c0001003, 4 t0001.c0001005, 5 t0002.c0002001, 6 t0002.c0002003 7FROM t0001 8LEFT JOIN t0002 9ON t0001.c0001002 = t0002.c0002002 10WHERE t0002.c0002005 > 30;
sql
1SELECT 2 companies.name as company_name, 3 companies.address as company_address, 4 companies.email as company_email, 5 accounts.name, 6 accounts.email 7FROM companies 8LEFT JOIN accounts 9ON companies.id = accounts.company_id 10WHERE accounts.age > 30;
前者を読むには対応表と比較し全てのカラムを頭の中で組み立てないといけないですが
後者を読む時間にはほとんどかかりません
#4
総合スコア146506
投稿2025/03/25 09:00
Railsなど、設定より規約系のフレームワークを使う場合には、こんなテーブル構造は「ありえない」以外の何物でもないです。
Railsでは、「主キーはid」、「usersテーブルにリレーションする列はuser_id」など、適切な名前をつければそれがフレームワーク内での意味を持つ、という構造になっていますが、列名が連番ではそれらをすべて無にすることになります。
#5
総合スコア762
投稿2025/03/25 09:21
編集2025/03/25 09:32対応表を見ながらの運用を続けられるのであれば特に問題はないと思います。
↑と思ったけど、データベースとしてはなんら問題はないのだがSELECTの時にいくつか問題が出る気がしました。
エイリアスの命名規則をどうするのかが難しい気がします。
concatで郵便番号と住所を繋げた文字列はどのような名前にするのが適切なんでしょうか。
それに、例えばPythonとか何らかのプログラムから取得した時にどうやってフローに埋め込みましょうか。
HTMLのtableに埋め込みたい時とか、無茶苦茶分かりづらい気がする。
適切にコード書く方法があればいい気がしていて、カラム名の問題という訳でもないか。
ほとんどの状況で何らかの変数に格納したいケースがありそうだが、変数名は番号になるのだろうか。
ネイティブアプリでUI要素と密接に関わりがある場合、UI要素のnameみたいな物は番号になっていて、そこで破綻しないようになっているのだろうか。
プロジェクトが汎用的なものなら行けるか...？
ちょっとでも複雑なソフトウェアになると、色々キツくないか。
会計事務所向けのソフトウェアとかだったら、事務の知識と符号化された列名を脳内でスッキリさせてコードかけるのか。
ユーザーから変な要望来たら、気が狂いやしないか。
この質問には関係ないけど、テーブル定義書とかそういうのがなんも無いプロジェクトの方が困る
#6
総合スコア28
投稿2025/03/25 09:42
避けるべきという判断です。
総合的な理由としては、トラブルが大問題に繋がりやすそう。不具合が発生し易そう、という理由から数字でのカラムはしないという判断です。以下が主に思った事です。
- 表が無かったりデータが欠損すると致命傷になる。
(無くしたり、時間が経って場所が分からなくなったり、更新を誰かが忘れてたり、複数人でやってると意外と良くあります……) - 列を間違えやすい
C00001をC00010と間違えて打っちゃった時とかめちゃめちゃ気づきづらいと思います。似たようなデータだったりすると特に！ - 仕様変更とかでテーブルの列を追加したり変えた時とかに凄い汚いコードになる。
テーブルAの列がC001,C002,C003,C040
みたいな打ち間違いなのか追加列なのかが分からない列とかが大量に増えると思います。3の次いきなり40なの！？ みたいな感じでイメージ的にもおかしくなってくると思います。 - 常に表を見ながらやらなければいけない。
（画面上の何処かに常に表を出してないといけなかったり等、意外と邪魔になる時があると思います） - 複数テーブルの複数列を弄る時、表のあっちこっちを見に行かなければならない
（純粋に面倒です）
特に1と2が致命的だと思います。
#7
総合スコア25410
投稿2025/03/25 10:03
編集2025/03/25 10:05データベース設計時にカラムIDを「c + テーブル番号 + 連番」と定義しています。
ビューとかインラインビューの時カラム名はどうなるのでしょうか？
また、単なる連番だと型属性とかは反映できませんね。
以下は考えておられるメリットの事ですが、
・テーブルの結合時にカラムIDが競合しない
データを取り出すだけのSQLしか記述していない？
・カラムID単体でテーブルIDが割り出せる
・テキスト検索で利用箇所の特定が容易
保守する時の話でしょうか。CRUD図は作成しないのでしょうか。
・固定長なのでコードが整理しやすい（何となくですが...）
可読性の話ですよね。メリットは感じませんが。
記述されたコードは見たくありませんし、仕様書も変換表見ながら解読しないと駄目だったりしたら、総じて恐ろしい事ですね。
ドメイン管理を学ばれた方が良いと思います。
#8
総合スコア23645
投稿2025/03/25 11:43
・テーブルの結合時にカラムIDが競合しない
私はどちらかと言うと積極的に競合させてます。競合が目的ではなくて、同じものは同じ名前に。
たとえば user.name, admin.name, shop.name, city.name なんとか名は全部 name。
これが name だったり namae だったり adana だったりしたら、、、
ruby使いなのですが、rubyは classが同じかどうかよりも このmethodをもってるか? のほうがどちらかと言うと大事なので、余計。
#9
総合スコア1109
投稿2025/03/25 23:35
編集2025/03/26 00:02カラムはテーブルに属していない。ドメインに属している
この設計は避けるべきでしょうか？
はい。ただし例外はあります。
・表内だけでカラム順序をたよりに機械的な操作を行う(異なる表のカラムの互換性は考えない)
・アプリケーション自動生成ツールの内部で使用され開発者の目に触れることがない
ExcelでカラムIDの対応表を別途用意しており、これを見ながら作業をしています。
ご自分で避ける理由を書いています。廃止してください。どうなりますか。
#7にもあるとおりカラムは背後にドメイン(定義域)を想定しています。DMLにはカラムレベルの操作(射影、結合、演算 ... )を含むので、カラムドメインの互換性を調べなければばりませんが、名前はよい手がかりになります。同じ名前は互換性を意味します。名前は認知負荷を下げて誤りの可能性を減らします。
カラムの名前
では、どんな名前をつけるべきか。次のような理想的な命名規則を考えてみます。
・カラム名はドメイン名で終わる(基本ドメインの数は少ない)
・ドメイン名の前に修飾語を付加する(修飾語によりドメインを限定(部分集合))
修飾語 _ 修飾語 _ ... _ドメイン名
プロジェクトで「データ辞書」を用意して、語と名前、意味記述を管理、テーブル定義を自動生成することがあります。(同名だけどドメインが異なる、別名だけどドメインが同じ、などの不具合解消にもデータ辞書を使います)
追記
カラム名を記号にするにしてもテーブル名をつけなければ、カラムをドメインごとに定義できるので、少し良くなります。
#10
総合スコア117571
投稿2025/03/27 06:11
もし連番ではない命名方法にすべき理由があれば教えていただきたいです！
連番にするということは列の順序に依存するということです。列順の入れ替えや使わなくなった列もなくすことができず管理の柔軟性を損ないます。エクセルでデータ管理するときもヘッダを「a」とか「b」とせず意味のわかる文字列で管理しますよね？つまりそういうことです。
またクエリーを組んでいるときも何と何がリレーションしてるか想像することも難しくメンテナンスは厳しいかなと。
連番管理であえて便利かなと思うのはプロシージャやファンクションで全列対象になにか処理をする場合などごくごく稀なケースでしょう。冗長に列を連番で増やすくらいなら、列は３つあればことたりidと列名と値だけ振っておけば十分です
#11
総合スコア23645
投稿2025/03/27 12:48
#追記_2
楽しんでください!!
#12
総合スコア142
投稿2025/03/29 05:46
みなさんと同意ですが一応！
私も「避けるべき」派です！
対応表の運用もしなければ行けないし、ズバリその時間が無駄！ミスのもと！だからです。
ただぁ〜...質問者さんの追記を見ての意見としては、やってみない（ミスや障害, 運用, etc...）とわからないことが開発世の中多いと思います。
すごい技術や設計を考える人だって、失敗した後に、どう失敗しないんだろう？を考えたからできたものだと思います（ただの妄想ですが笑）
チャレンジして、考えてやってみて、人の意見を聞いて反省し改善や勉強をしようとしている質問者さんは素晴らしいなと感じました！
ぜひ開発楽しんでください！
#13
総合スコア21
投稿2025/04/01 00:26
今は避けるべき派です.....が昔はこういう設計したなあって思い出しました。
50近いおっさんの昔話として聞いて。
c + テーブル番号 + 連番になっていることの利点は単純にコードでSQL文を生成しやすいんです。関数で引数与えてそれを文字列として組み合わせればSQL作れちゃうじゃないですか。更に連番になっているので1−100までのカラムを出力にいれるってのもループ回せば簡単です。なのでフレキシブルな出力を要求される要件の場合はこんな設計だったなーってのがあります。テーブル名やカラム名の変換用テーブルもてば良いってのもあったけど、昔はそういうメモリもケチっていた時代があったのです。
今は他の方々が言う通りやるべきではないですよこんなの。そういう設計してきた人がいたら「昭和か」で返していいですマジで。そんなところでメモリケチる時代じゃねえだろと。
#14
総合スコア9
投稿2025/04/01 03:45
命名規則はそのチームが一番運用しやすいもので決めるのが本質ですが、世の中には同じような問題で苦慮してきた人たちのナレッジが蓄積されています。
これらは一般に標準と言われるもので
DOA（データ中心アプローチ）的な標準では次のように推奨しています。
実体＋属性＋ドメイン
チームの成長に合わせて色々試行錯誤して、新たなナレッジとして標準化されると良いですね。
#15
総合スコア984
投稿2025/04/01 04:11
べき とは言いませんがが私は避けます。
質問文を読むに、質問者さんは優秀なんだろうなと。
複数人開発経験ないとのことですが、
今後大きいプロジェクトを動かす場合にはやはり複数人開発は避けて通れないでしょう。
今まで連番式カラムで実装したことありませんが
「id, name...」方式ですら複数人いると意思疎通に時間がかかります。
質問者さんのメリットを帳消しにするデメリットになるだろうなと推察します。
#16
総合スコア1
投稿2025/04/11 07:43
編集2025/04/11 07:447~8年くらいエンジニアをしている現代プログラマーです
結論、（誰にも引き継ぐことはできないかもしれませんが）個人開発はそれで大丈夫です
例えば、CMSはそういう感じでテーブル生成してるかもしれません
そういうものは「自動で生成するもの」となっています
大昔の開発現場では、マシンスペックが低くて(メモリが少なかったので)
a1みたいな変数名や対応表が存在していたと聞いています
「現代までそのような命名や対応表はほぼ残っていない」
が一番回答として適切かもしれませんね（組み込みならあるかも？）
個人的には「対応表の紛失リスク」が一番大きいかなと思います
特に現場ではドキュメント関連のファイルがたくさん増えるので、対応表を探す手間がでたり
テーブル構成などを大きく変更するために対応表を読みながら思考をまとめる辛さもありそうです
一般的な教材やプログラミングスクールって「作る」ことは教えてると思いますが
作る前と作った後のことを基本説明しないのが良くないですよね
自分の成果物は自分以外の人間が読む前提があるということ
これを意識させてくれるような教材が増えることを願っています
個人で作れるものの規模には限界があるので…
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。