これは、しばらくの間、私を悩ませてきた、と私は右を感じ解に到達することはできません... OOオブジェクトのプロパティのための通常の命名規則がcamelCase形式される言語、およびANを考えるとプログラミング言語がcamelCaseを使用している場合、PostgreSQL識別子の下線またはキャメルケース？
このようなオブジェクトの例：
{
id: 667,
firstName: "Vladimir",
lastName: "Horowitz",
canPlayPiano: true
}
この構造をPostgreSQLのテーブルでモデル化する方法を教えてください。
は、三つの主要なオプションがあります。
- 引用符で囲まれていないキャメルケースの列名にアンダースコア
と
引用符で囲まれていない識別子は、自動的に小文字に変換されます。つまり、
canPlayPiano列の表を作成できますが、大文字と小文字が混在してもデータベースに到達することはありません。テーブルを調べると、カラムは常にcanplaypiano- psql、pgadmin、結果の説明、エラーメッセージ、すべてに表示されます。引用符付きの識別子は大文字と小文字を区別しますが、そのように作成すると、は常にに引用符を付ける必要があります。 IOW、
"canPlayPiano"列のテーブルを作成すると、SELECT canPlayPiano ...は失敗します。これにより、すべてのSQLステートメントに多くの不要なノイズが追加されます。下線付きの小文字名は明白ですが、アプリケーション言語が使用している名前とうまくマッピングされません。ストレージには別の名前（
can_play_piano）とコード（canPlayPiano）を使用することを忘れないでください。また、プロパティとDB列の名前を同じにする必要がある特定のタイプのコード自動化もできません。
私は岩石と硬い場所（そして大きな石; 3つのオプションがあります）の間に挟まれています。私が何をするにしても、いくらかの部分は気分が悪くなるでしょう。ここ10年ほど前から、私はオプション3を使っていましたが、もっと良い解決策があることを願っています。
ご迷惑をおかけして申し訳ありません。
PS：SQLの標準ではなく、PostgreSQLの標準への適合で、引用符の大文字と小文字の区別がどこから来ているのか分かります。私はそれがどのように機能するか知っているPGが識別子をどのように扱うかについての説明よりもベストプラクティスに関するアドバイスにもっと興味があります。
あなたはすべて小文字で行く場合でも、私はあなたが常に生成されたクエリ内の引用符ですべての識別子をラップしてデータベース抽象化レイヤを持つことをお勧めします。新しいリリースでどのような新しいキーワードを使用するかを常に予測できるわけではないので、名前を矛盾させないようにするには引用符で保護してください。 – kgrittn
"ベストプラクティス"はありません。世界の半分はアンダースコアを好み、残りの半分はアンダースコアを嫌う。世界の半分がイニシャルキャップを好み、残りの半分がイニシャルキャップを嫌う。世界の半分は大文字小文字を区別しませんが、残りの半数は大嫌いです。これらの問題は純粋に主観的なものなので、これらの半分のペアは決して合意にはなりません。自分自身を好意的にして、本当に重要なことを心配してください。それは、それがするべきことをするコードを書くことです。 –
あなたが使用した回避策を教えていただけますか？私は同じ状況で渡っている、私はアンダースコアのパターンにあるテーブルの列とマップする必要があるcamelCaseのオブジェクトのプロパティがあります。私は数時間を過ごしましたが、まだ良い解決策は見つかりませんでした。 –