列名の接頭辞が悪い習慣と見なされるのはなぜですか？

人気のあるSOの投稿によると、テーブル名にプレフィックスを付けることは悪い習慣と見なされています。私の会社では、すべての列の前にテーブル名が付いています。これは読みにくいです。理由は定かではありませんが、この命名は実際には会社の標準です。命名規則に我慢はできませんが、その根拠を裏付けるドキュメントはありません。

私が知っているのは、AdventureWorksを読む方がずっと簡単だということだけです。で、この私達の会社DBは、テーブルが表示され、人とそれは、列の名前を指定できます。

Person_First_Name
または
Person_Person_First_Name（おそらく、2xの人を見る理由を聞かないでください）

列名に接頭辞を付けるのはなぜ悪い習慣と見なされるのですか？アンダースコアはSQLでも悪と見なされますか？

アンダースコアは入力するのが難しいだけでは悪ではありません。悪いのは、既存のオブジェクトをすべて修正せずに標準を変更することです。これでpersonId、Person_idなどが得られ、アンダースコアを使用しているテーブルと使用していないテーブルを思い出せません。命名の一貫性（個人的に名前が気に入らない場合でも）により、コーディングが容易になります。

個人的には、列でテーブル名を使用する必要があると思う唯一の場所はID列です（IDだけを使用することは、データベースレポートでアンチパターンです。レポートを作成するたびにクエリ内に12列。

ただし、成熟したデータベースでは、既存の標準を変更するよりも多くの作業が必要です。それが標準であることに同意し、先に進むと、最初に修正する必要があるはるかに重要なことがあります。

列名のプレフィックスの引数は、複数のテーブルを結合するとき、およびクエリ作成者がエイリアスを使用しないときに、名前の「衝突」を防ぎます。

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

どちらのクエリにも、所属するエンティティに「伝える」ことなく、 2つの「名前」列（name_1、name_2）があります。また、生成された列名を確認することはできません（name_2またはname_3または...になります）。テーブル名の接頭辞を使用すると、列名はperson_name、company_nameになるため、エンティティが属する各名前がわかり、さらに列名が一定のままであることがわかります（たとえば、JDBCを使用してJavaで取得する場合） ）。

エイリアシングを使用する場合、両方の引数は無視できますが、企業で実施されているコーディング規則のほとんどは、多くの（後輩）プログラマーが優れた慣行に従わない結果であると思います。この場合、たとえば、SELECTステートメントでワイルドカードを使用すると、名前のプレフィックスなしで問題が発生する可能性があります。

テーブル名と列名のアンダースコアについては、名前に小文字と区切り文字としてアンダースコアのみを使用しているため、広く使用しています。小文字のみを使用すると、識別子をSQLキーワード（すべて大文字で入力）と区別するのに役立ちます。

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'

これらの種類のプレフィックスを列名に追加すると、テーブルの展開がより難しくなります。例として：最終的にテーブル名を変更する必要があることに気づいた場合、テーブル構造全体を変更する必要があります（つまり、テーブルの名前だけでなく、そのすべての列の名前）。これにより、テーブルのインデックスとそれをクエリするクライアントのコードを更新することも難しくなります。

よくあいまいになる一般的な列名（通常はIDのみ、場合によっては名前）に（リンク上のPatrick Karcherの回答に従って）慎重に使用すると例外があります。

別のベストプラクティスは、クエリ内の列とオブジェクトを常に修飾することです。そのため、列のプレフィックスは意味がなくなり、コードが乱雑になります。

これらを比較してください：一番簡単なのはどれですか？

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person

一般に、ユビキタス標準は存在しないようです。あなたがリンクした質問には、全く異なる慣習で投票されたいくつかの回答があります。もちろん、誰もが自分の基準を守るつもりであり、プロジェクトで一貫した規則を維持することがはるかに重要です。

とは言っても、列名の前に付けるのはやり過ぎのようです。作業しているテーブルは既にわかっているため、同じ名前を持つ異なるテーブルの2つの列がある状況は、テーブルまたは列のエイリアスを使用して簡単に解決できます。

TSQLでは、あいまいさを避けるためにTableName.FieldNameの形式でフィールドを参照できるため、フィールド名にテーブル名を追加すると、実際には読みにくくなり、TableName.TableName_FieldNameなどになります。アンダースコアを使用するかどうかは、個人的な選択の方が多いと思います。私はキャメルケースを好み、サフィックスまたは同様のテーブル名_Tempを追加したいときは_を使用しますが、それは私だけです。

私はかつて、短いコードを使用して列にプレフィックスを付けることにしたシステムに取り組んでいました。PKフィールドは接頭辞として「フルテーブル名」を使用し、他のすべての列は接頭辞として一貫して2〜4文字を使用していました。各列では、サフィックスとしてデータドメインも使用しました。一貫して行うと、非常にきれいできれいになります。あるタイプまたは別のタイプの命名標準がずさんなコーディングに関係していることはナンセンスです。一貫した標準の存在が重要です。明確な標準がないために一貫性のない多くのデータベースを見てきましたが、他の何よりもデータ構造に問題があるかもしれないことを私に示すでしょう。データベースの設計者がオブジェクトとその子に一貫して名前を付けることができない場合、

接頭辞は、防止するように設計された問題を引き起こすため、悪い習慣です。前に述べたように、接頭辞付きの列は非常に読みにくいです。2つのテーブルを結合するクエリで列名が重複する場合は、それらを解決するか、ビュー、ストアドプロシージャ、または特定のテーブルに絶えず結合している場合にそれを行う表形式のユーザー定義関数を解決できます。

テーブル名にアンダースコアを使用する限り、それは宗教的な議論です。最終的には、可視性が向上し、物事が簡単になります。通常、列名または表名にスペースや表を含めることはありません。ただし、レポートパッケージでのみ使用されるか、CSVファイルにエクスポートされるテーブルまたはビューについては例外を作成する場合があります。

多くのデータベースでは、列名の文字数（つまりOracle）に厳しい制限があります。

長い列名を許可するデータベースで作業しているが、後でその構造を別のデータベースシステムに移行することに決めた場合、接頭辞により列名が無効になる可能性が高くなります。

現在SQL Serverを使用していますが、将来を予測することはできません。また、将来、ソフトウェアが複数のデータベースで動作しなければならない可能性があります。

データディクショナリ（または「レジストリ」）の作成を検討してください。つまり、モデル内のすべてのデータ要素（名前、説明など）を含むドキュメントを意味します。モデルの実装から独立している必要があります。たとえば、テーブル名については言及しないでください。「ID」、「タイプ」、「コード」などの名前をどのように明確にしますか？

1つのアプローチは、国際規格ISO / IEC 11179のガイドラインに従うことです。結局のところ、なぜ車輪を再発明するのでしょうか？基本構造は次のとおりです。

[Object] [Qualifier] Property RepresentationTerm

要素間に区切り文字がある場合：列名にスペースが含まれているとSQLはうまく機能せず、アンダースコアは視覚的にうまく機能します。

あなたの組織のだれかがのような要素名を思いついたとき、これらのガイドラインに従おうとしていると感じていますPerson_Person_First_Name。

私が見せたい例は、UK Nation Health Service（NHS）データ辞書です。

ですから、あなたが扱う必要のある命名規則は、それほどひどいとは思いません。

SQLでの実装例では、のようないくつかの民族がオブジェクトを省略し、テーブル名は、コンテキストなどを提供修飾子、プロパティのサブ要素はperson_first_nameなりfirst_nameにPersonただし、データ要素は、単にその名前を親指のルールを変更するべきではないと、テーブルなど物理モデル内の場所が適切なためです。このルールに従うのは良い考えではないと思う人には、使用したすべての名前のバリエーションを文書化するタスクを与える必要があります:)

Joe Celko's Programming Styleには、列名の区切り文字として下線を好む証拠を含む、ISO 11179の素晴らしい要約があります。

データがどのテーブルから来たのかをコードで簡単に知る人もいますが、オブジェクト指向システムについて話している場合は、名前のコンテキストを使用してそれがどこから来たかを知る必要があります。この場合はテーブル名です。

個人的には、テーブル名のプレフィックスは、開発者があまり熟練していないことを示しており、深く掘り下げると、他の多くの悪いコーディング規約が見つかります。アプリにテーブルが多すぎる、バグがあるなどと推測する必要がある場合