66

これはしばらく私を悩ませてきました、そして私は正しいと感じる解決策にたどり着くことができません...

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

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

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

主なオプションは次の 3 つです。

  1. 引用符で囲まれていないキャメルケースの列名
  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 が識別子をどのように処理するかについての説明よりも、ベスト プラクティスに関するアドバイスに関心があります。

4

3 に答える 3

45

の列が の場合、PostgreSQLエイリアスunderscoresを配置できますが、二重引用符を使用できます。

例 ：

SELECT my_column as "myColumn" from table;
于 2013-12-10T10:03:44.230 に答える
30

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

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

列名と識別子の間の変換が面倒な場合は、コンピューターに任せてください。コンピューターはそのようなことを得意としています。そこにある900万のデータベース抽象化ライブラリのほとんどすべてがそれを行うことができると思います。動的言語を使用している場合、CamelCase で列名を識別子に交換するには、2 行のコードすべてが必要です。

于 2012-06-30T05:38:18.647 に答える