0
1
テーマ、知りたいこと
MySQLの命名規則で「カラム名だけをキャメルケース」という案を考えたのでが、おかしいでしょうか？
（ただし「テーブル名とインデックス名はスネークケース」です。）
背景、状況
PHPとJavaScriptとの兼ね合いから、MySQLカラム名をキャメルケースにしたいと考えています。
なぜなら、PHPの慣習でクラス内変数はキャメルケースです（それに私はクラス外でもそうしようと思っています）し、JavaScriptの慣習もキャメルケースなのに、MySQLのカラム名がスネークケースでは下記のような// 不統一生じるためです。
PHP
1$row = DBからSELECTしたレコード; 2$kindId = $row['kind_id']; // 不統一
一方で、次の Qiita では「> 大文字を利用しない」と「> 複数単語の連携は スネークケース」が 推奨されており 多くのプロジェクトで共通していると紹介されており、
https://qiita.com/genzouw/items/35022fa96c120e67c637#大文字を利用しない
その理由は「> DBにより大文字小文字を区別するもの、しないものなどがあるため小文字で統一を図る」と記載がありますが、
しかし、次の StackExchange では「> As for column names, it should not be an issue.」と記載があるので、どうやらカラム名は問題ないように思われます。
https://dba.stackexchange.com/questions/91606/is-camel-case-for-column-names-safe
そこで、今回の案に至りました。
この案においては、MySQL・PHP・JavaScript間の変数名がキャメルケースで統一できる代わりに、MySQLのカラム名とテーブル名がもちろん不統一になりますが、テーブル名なんてクエリ文にしか記載しませんよね。
上記のような// 不統一と比べれば圧倒的に不統一感は減らせると個人的には感じます。
ただ、素人案なので将来的な懸念や実装での問題を想定するまでに至っておりません。
有識者の皆様、こちらの案についてアドバイスを頂けませんでしょうか。
（カラム名だって大文字はマズイ、あまり慣習的でない実装は避けた方がいい、逆にPHPとJavaScript側をスネークケースにした方がいい、などなど。）
どうぞ宜しくお願い致します。
回答10件
#1
総合スコア28673
投稿2023/07/24 06:37
編集2023/07/24 06:44別にいいんじゃないですか？
むしろなぜそんな記事に従おうとしたんでしょうか？
ただしカラムの大文字小文字は区別されないかもしれないので、注意は必要です。
#2
Zuishin様、アドバイスありがとうございます。
別にいいんじゃないですか？
これは「その案は奇妙だけど、チーム内で好きなルールを共有できればなんだっていい」でしょうか？
それとも「その案はたしかにいいね」でしょうか？
むしろなぜそんな記事に従おうとしたんでしょうか？
記事の良し悪しを判断できない素人なので・・・
ただしカラムの大文字小文字は区別されないかもしれないので、注意は必要です。
なるほど。確かにそうでした。ご指摘誠にありがとうございます。
この問題については「さすがに同一テーブルで大文と小文字を混同したカラム名を作ってしまうリスクは低いから大丈夫だろう」と高を括っています。
無論「小文字のみ」として対処すればこのリスクは0にできますが、そもそものリスクが低いため問題視しなくていいのかなと。甘いでしょうか？
この低いリスクに対処することで、// 不統一が起こることの方をむしろ避けたいというのが個人的な意見です。
#3
総合スコア28673
投稿2023/07/24 06:47
記事の良しあしというか、その記事には「こういう規約が多いよ」としか書いていませんよね？
従うものではなく参考にするものでしょう。
グループで開発していて規約があるならそれに従えばいいし、一人で開発するなら別に構わないと思います。
#4
Zuishin様、ご返答ありがとうございます。
従うものではなく参考にするものでしょう。
たしかに仰る通りかと思います。当質問では参考にした上で私なりの案を出し、その是非を知りたいと思っております。
グループで開発していて規約があるならそれに従えばいいし、一人で開発するなら別に構わないと思います。
これも全く仰る通りかと思います。ただ、例えば極端な話「大文字と小文字を交互にする」というのはあまりに奇妙ですから、それをグループや個人開発の規約に採用しようとした相手がいれば「それはかなり奇妙だよ」とご指摘が入るかと思います。
今回の案はそこまで極端ではないにせよ、「どの程度奇妙なのか」（または決定的な問題があるので全然ダメなのか、それともちょっと良いのか、はたまたとても優れた最強の案なのか）というような、案から得られる印象の評価の程度を知りたいと思っております。
一人で開発するなら別に構わないと割り切ってしまうとあらゆる方法論が過分に正当化されてしまいますので、様々な規約を知り、自ら考え、みなさまからのご指摘を頂戴したい。という意図です。
#5
総合スコア2043
投稿2023/07/24 08:43
カラム名だけをキャメルケース
個人的にはキモいので反対です (感情の問題)。
あえて理屈を考えてみると、PHP や JavaScript と統一できるってのは言語と DB を密結合させすぎだと思います。Python だとスネークケースになりますがそれはどうしますか?
それはそれとして、kind_id で検索すればそれは DB のカラムであるってのは嫌いじゃないんですけどわたしだけですかね。特に SQL は文字列として作成することが多くその場合はエディタ機能で変数名置換ができません。なのでカラム名を変えたければ文字列置換、変数名を変えたければエディタ機能で変数名置換、と。
#6
総合スコア4443
投稿2023/07/24 09:28
テーブル名やカラム名などのキャメルケースについて、賛成できない理由を書きます。
- キャメルケースで大文字小文字が区別されないと、人間にとっては異なるものがコンピュータには同一視されます。たとえば
NowHereとNoWhereは区別されない恐れがあります。スネークケース等ではこういう問題は起きません。now_hereとno_whereは大文字小文字の変換を経たとしても明確に区別されます。 - 標準SQLでは、大文字小文字は区別されないようです。つまり、大文字小文字を区別しないDBMSは多いです。Oracle Databaseでは特に指定しなければすべて大文字とみなします。PostgreSQLも特に指定しなければ区別しません。
- MySQLではさらにやっかいなことに、環境によって大文字小文字は区別されたりされなかったりします (識別子の大文字と小文字の区別)。つまり、あるプラットフォームで作成したMySQLデータベースを他のプラットフォームに移行すると、期待通りに動作しないかもしれないということです。
要するに、キャメルケースではデータベースやシステムそのものを移行すると識別子の衝突や混同が起きて利用できなくなる可能性があります。カラム名等を再検討する必要があり、事実上の再設計になります。
そもそも、SQLとPHPは別の言語なので、識別子の習慣が異なってもおかしくないと思います。「それはキモい」という声が出るのもそれが習慣としてそれぞれの言語コミュニティに染みついているからでしょう。
あと、その提案はスネークケース派との終わりのない戦いに突入するだけでなく、アッパーキャメルケース派とロウアーキャメルケース派との間の内戦も始まってしまって収拾がつかなくなるのでイヤ。
#7
68user様、アドバイスありがとうございます。
そういえばPythonや検索性など考えておりませんでした。
そう考えるとスネークケースもいいですね。
ありがとうございます。大変参考になりました。
#8
ikedas様、アドバイスありがとうございます。
要するに、キャメルケースではデータベースやシステムそのものを移行すると識別子の衝突や混同が起きて利用できなくなる可能性があります。
コンピュータの区別については、StackExchange に挙げているようにテーブル名の問題が大きく、カラム名の問題は「同じカラム名をつけるわけがない」と高を括っております。
その「つけるわけがない」という低すぎるリスクに対処するためにスネークケースにして// 不一致を起こすくらいなら、その低すぎるリスクへの対処はせず// 不一致を起こさない方が良いのではないか。というのが今回の案でした。
けれど、私はuser_idとuserIdのような同じ意味のカラムしか考えていませんでしたので「つけるわけがない」と思っていたのですが、そういえばたしかにNowHereとNoWhereのような違う意味のカラムを考えると「つけるわけがない」とは言いきれなそうです。低すぎるリスクとは言えませんね。
それに、
そもそも、SQLとPHPは別の言語なので、識別子の習慣が異なってもおかしくないと思います。
ということは「そもそも// 不一致はおかしくないのだ」とのことだと思いますから、どうやら// 不一致がおかしいだなんていうのは素人の勘違いだったようですね。
ありがとうございます。大変参考になりました。
#9
総合スコア4443
投稿2023/07/29 00:31
その後気づいたことを記しておきます。
先述の通り、PostgreSQLやOracleでは「指定しなければ」大文字小文字を区別しないです。指定すれば大文字小文字を区別したカラム名を作成することができます (NowHereとNoWhereというカラムを持つテーブルを作れる)。
MySQLにはそのような指定をする方法がなく、カラム名の大文字と小文字は常に区別されません (NowHereとNoWhereというカラムを持つテーブルを作れない)。このあたりの事情から「MySQLでは」「カラム名だけを」キャメルケースにしてもよいではないか (区別できないものは作成されないから) というご主張でもあるのかと思いました。
ところで、このカラム名についてはクライアントAPIが返す結果にもDBMSごとに違いがあるようです。
- MySQLの場合、クエリでの結果カラム名の大文字小文字が、結果でも反映されます (カラム名の大文字小文字は区別しないにもかかわらず)。
[db]> SELECT NoWhere FROM table; +-----------------------+ | NoWhere | +-----------------------+ ... - Oracle Databaseでは、特に指定しない場合、カラム名はすべて大文字とみなされます。つまり、クエリでカラム名を小文字で書いたとしても、結果に含まれるカラム名は大文字です (結果に小文字のカラムがなくて焦ったりする)。
- PostgreSQLでは、特に指定しない場合の結果は小文字となるようです。
ORマッパなどではこのような仕様の違いを吸収するために「結果のカラムをすべて小文字に変換してから扱う」といった対応をしたりもしています。
MySQLのAPIに直接アクセスするだけならうまくいきそうですが、応用を考えるとこのようにキャメルケースを使いたくても使えなくなる場合もありそうです。
#10
総合スコア146544
投稿2023/08/03 02:37
PHPとJavaScriptとの兼ね合いから、MySQLカラム名をキャメルケースにしたいと考えています。
Ruby（Rails）ではそもそもメソッド名がsnake_caseを使う慣習なので、DBもそれに合わせるほぼ1択となります。
一方で、camelCaseとされることの多いJavaScriptとの兼ね合いでは、JSONデータをどちらの形式にするか悩むこととなります。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。