web-dev-qa-db-ja.com

プログラミング言語がcamelCaseを使用する場合、PostgreSQL識別子のアンダースコアまたはcamelCaseですか？

これはしばらく私を悩ませており、私は感じる解決策に到達することはできません 正しい...

OOオブジェクトプロパティの通常の命名規則がcamelCasedである言語と、次のようなオブジェクトの例を考えます。

{
    id: 667,
    firstName: "Vladimir",
    lastName: "Horowitz",
    canPlayPiano: true
}

PostgreSQLテーブルでこの構造をどのようにモデル化すればよいですか？

主に3つのオプションがあります。

  1. 引用符で囲まれていないcamelCaseの列名
  2. 引用符で囲まれたキャメルケースの列名
  3. アンダースコア付きの引用符で囲まれていない（小文字の）名前

それらにはそれぞれ欠点があります。

  1. 引用符で囲まれていない識別子は、自動的に小文字に変換されます。これは、canPlayPiano列を持つテーブルを作成できることを意味しますが、大文字と小文字の混在はデータベースに到達しません。テーブルを検査すると、列は常にcanplaypianoとして表示されます-psql、pgadminでは、結果、エラーメッセージ、すべてを説明します。

  2. 引用符で囲まれた識別子は大文字と小文字を区別しますが、そのように作成すると、常に引用符で囲む必要があります。 IOW、"canPlayPiano"列を持つテーブルを作成すると、SELECT canPlayPiano ...は失敗します。これにより、すべてのSQLステートメントに多くの不要なノイズが追加されます。

  3. アンダースコアを使用した小文字の名前は明確ですが、アプリケーション言語が使用している名前にはうまくマッピングされません。ストレージ（can_play_piano）とコード（canPlayPiano）に異なる名前を使用することを忘れないでください。また、プロパティとDB列に同じ名前を付ける必要がある特定の種類のコード自動化を防ぎます。

だから私は岩と硬い場所（そして大きな石。3つの選択肢があります）の間に挟まれています。私が何をするにしても、ある部分は気まずく感じるでしょう。過去10年ほど、オプション3を使用してきましたが、より良い解決策があることを願っています。

アドバイスをいただければ幸いです。

PS：ケースの折りたたみと引用符の必要性がどこから来ているのか、SQL標準、またはむしろPostgreSQLの標準への適合を理解しています。私はそれがどのように機能するか知っています。 PGが識別子を処理する方法についての説明よりも、ベストプラクティスについてのアドバイスに興味があります。

ooppostgresqldatabase-designnaming-conventionscamelcasing
48
Zilk

PostgreSQLがアンダースコア付きの大文字と小文字を区別しない識別子を使用している場合、アプリケーション内のすべての識別子を同じように変更する必要がありますか？明らかにない。では、なぜ逆が合理的な選択だと思いますか？

PostgreSQLの規約は、標準への準拠とユーザーの長期的な経験の組み合わせによって生まれました。それにこだわります。

列名と識別子の間の変換が面倒になる場合は、コンピューターにそれを行わせてください-彼らはそのようなことを上手です。私は、そこにある900万のデータベース抽象化ライブラリのほぼすべてがそれを行うことができると推測しています。動的言語を使用している場合、2行すべてのコードを使用して、列名をCamelCaseの識別子に交換します。

29
Richard Huxton

PostgreSQLの列がunderscoresである場合、エイリアスを置くことができますが、doule-quotesを使用できます。

例：

SELECT my_column as "myColumn" from table;
18
Mirza Selimovic