非常に短縮されたテーブル名を使用する理由はありますか？

ベンダーのアプリケーションのデータベースセットアップを使用していますが、データベーステーブル名は恐ろしく読みにくく、どこに保存されているかに関するドキュメントはありません。プロプライエタリアプリでテーブル構造を難読化する理由はわかりますが、このアプリケーション（エンタープライズリソースプランニング）のセールスポイントの1つはカスタマイズ性でした。

テーブル名は、aptrx（買掛金勘定取引）およびapmaster_all（奇妙なことに、これはベンダーテーブルです）のようなものです。それは非常に複雑なデータベースなので、慣習に何らかのロジックがあるのか​​、それとも単に意図的にまたは他の方法で難読化されているのか疑問に思っていました。

私の知る限り、テーブル名の長さはパフォーマンスに顕著な影響を与えません、正しいですか？データベースは非常に複雑（数百のテーブル）なので、ソートは理にかなっていますが、AccountsPayableTransactionsがaptrxよりも好ましくない理由は想像できません。

Oracleでは、テーブル名に30文字という長年の制限があります。これは、元の16ビット環境に基づいたレガシーな問題だと思います。
テーブル名の長さは、すべての名前をデータディクショナリに格納し、クエリ用に解析する必要があるため、パフォーマンスにわずかな影響を与える可能性がありますが、ヒットを測定できるとは思いません。

短いテーブル名のより重要な効果は、作業が難しいことです。私もエンタープライズデータベーススキーマを短い名前で維持する必要があります。短いテーブル名を持つ正当な理由はありません。メンテナンスの容易さは、毎回難読化や古いDOS習慣に勝ります。

私はまだ言われるか、または詳述される必要がある2つのことがあると感じます：

1. 物に名前を付けることは、思ったほど簡単ではありません

   コンピューターサイエンスには、キャッシュの無効化と名前付けという2つの難しい問題しかありません。フィル・カールトン

2. 短い意味のない名前は常に悪いのですが、長い名前は必ずしも良いとは限りません-私たちの脳には、驚くほど低い組み込みのtl; drしきい値があります。通常は30文字で十分ですが、そうでない場合は例外的なケースにも対応できるようにRDBMSを使用します（言語の場合と同様に、あまり頻繁に話さないこと-制約名など、短い名前は、常にクエリを実行するテーブルに役立ちます）

私はいつも名前を選ぶのに時間がかからないように誘惑されており、もしそうなら後悔する-名前の変更はめったに起こらない

怠惰。IntelliSenseとサードパーティのオプションにより、タイピングは正当化するのが本当に難しい言い訳になります。名前には意味のある読みやすい単語が含まれていると思います。

テーブル名は、aptrx（買掛金勘定取引）およびapmaster_all（奇妙なことに、これはベンダーテーブルです）のようなものです。それは非常に複雑なデータベースなので、慣習に何らかのロジックがあるのか​​、それとも単に意図的にまたは他の方法で難読化されているのか疑問に思っていました。

よく知られている略語は、通常、物事を綴るよりも望ましいです。略語が一部の人にはよく知られているが、十分な人ではない場合、略語の呼び出しを停止し、コードの呼び出しを開始します。

略語は厳しい制限があるプラットフォームでスペースを節約しますが、現在では30年前ほど重要性は低くなりました。（1980年代にテーブル名を6文字または8文字に制限していたシステムで作業したことを思い出すようです。）

略語は通常、略語が適切に行われている限り、表名と列名を読みやすくします。APのコードに終日取り組んだ場合、「accounts_payable_transactions.invoice_number」ではなく「ap_trx.inv_num」のような列名を読みたいと思います。（私はアンダースコアが好きです。）長いテキスト名を入力することは、優れたテキストエディターではあまり問題になりません。

会計システムでは、「ap」と「trx」の両方がよく知られている略語です。その他には、売掛金勘定、総勘定元帳、および一般仕訳の「ar」、「gl」、および「gj」が含まれます。

適切に設計されたシステムでは、「aptrx」という名前のテーブルに買掛金取引が見つかった場合、artrxの売掛金取引、gltrxの総勘定元帳取引などを検索したいと考えています。「apmaster_all」は少し不可解ですが、「armaster_all」も見つけた場合は、最初のベンダーがすべてのベンダー（アクティブまたは非アクティブベンダーではなく）を保有し、2番目のベンダーも同様にすべての顧客を保有していると推測します。

他の問題領域では、他のよく知られた略語を見つけます。アドレス指定では、住所の「addr」、ストリートの「st」、米国郵政公社の「usps」、ユナイテッドパーセルサービスの「ups」、郡の「cty」、ゾーン改善の「zip」などの略語があります。コードなど。

これを難読化とは呼びません。買掛金トランザクションが「cdrs21」という名前のテーブルに格納されている場合、その難読化を呼び出します。（私はかつて、すべてのメインフレームアセンブラモジュールをそのように命名した会社で働いていましたが、難読化ではなく、文字の制限です。）

しかし、有用なデータベースは成長し、データベースが大きくなると問題に直面します。データベースに問題のあるドメインを追加すると、よく知られた略語が衝突する状況に陥ります。メディアを扱う場合、「ap」は「Associated Press」、「alternative press」、または「advance placement」と略すこともできます。それが起こったら、略語を放棄するか、コードに切り替える時間です。組織が大きくなるほど（そしてデータベースが大きくなるほど）、コードを見つける頻度が高くなります。

「私の神、ゴーグルは、この恐ろしい命名規則に対して何もしません」という話に賛成です。私の最後の環境のデータ管理チームは、短縮されたテーブル名を使用する理由は、テーブルと列に18文字というDB2の制限（z / OSとSQL ServerにDB2があった）であると述べました。私は、これがIBMのサイトのドキュメントと不正確であることをすぐに指摘しました。その後、MF騎手によって反証されたデータベースと対話する必要がある場合、COBOLの問題である（そう、積極的に開発されたCOBOLである）と述べました。最後に、彼らの反応は、それが私たちの公開標準だということでした。

標準化委員会に長さを18文字から32文字に増やすよう請願し、30文字の制限を受けました。その結果、テーブルが「SR_M_DLY_ADV_PRD_S」の不要な名前から「IDX_FDSHRCLAS_LIF_RTRN_STATS_X」FMLになりました。

だから、私の十数年の経験では、短縮されたテーブル名は具体的なメリットをもたらさず、結果として画面上のゴミを意味のある識別子に変換するために常にデータ辞書を参照する必要があるため、開発とメンテナンスのコストが高くなります。これは、私が作業した論理的に名前が付けられたエンティティとは対照的であり、直感的に名前が付けられているため、ほとんどがメモリから再作成できます。

それは習慣です（ケビンスキーに同意します）。これは、オペレーティングシステム（DOS、Windowsなど）とその名前を処理しないソフトウェアの制限（名前の長さ、複雑な名前の単語間のスペース、多言語など）に対する古い（おそらく存在する）問題に対する反応でした。経験豊富な人々は言った：「そうする（短いものを使用し、下線の名前で区切る）、すべてが大丈夫だろう。」

私は、ポスターによる前述の理由のために記述的な命名法を使用するのが好きです。

しかし、別の利点もあります。たとえば、わかりやすい名前を付けると、ネストされた名前を使用できます。Employeeというテーブルがあるとします。別のテーブルとの関係がある場合は、EmployeeAddressと呼ばれます。またはEmployeeDepartment。不可解で簡潔な名前付けでは、これはほとんど不可能です。

各列の基礎となる定義がどの程度複雑かによって異なります。これらの種類の非常に説明的な列名を見ると、人々はメタデータ管理に不精になり、実際には不完全な説明でさえあると思います。あなたは、なぜ何を短縮するのかを尋ねるかもしれません。