私はいくつかのブレント・オザールのビデオを見ています（例えば、このような）、彼はテーブルの前に‘tbl’またはを付けないことを提案してい‘TBL’ます。

インターネット上で、ドキュメントに何も追加されず、「読むのに時間がかかる」というブログを見つけました。

質問と考慮事項

• これは本当に問題ですか？なぜなら、最初のdbaジョブ以来、テーブルの前に 'tbl'を付けているからです（シニアDBAから組織のためにそれを行うように言われました）。
• これは私が取り除く必要があるものですか？いくつかのテストを行い、非常に大きなテーブルをコピーして「tbl」プレフィックスを付け、もう一方のテーブルはそのままにして、パフォーマンスの問題に気付きませんでした。

私はかつてテーブルを持っていて、それは光沢があり、きれいでした。組織のすべての金融取引を保持していました。その後、データの読み込みを開始しました。

今月は、必要に応じて何度でも値を記述および再記述できます。月の最後の10日間で、番号を再記述します-> ETL処理を実行します-> 1日に数回レポートを確認します。月が完了すると、書籍は封印され、値を変更できなくなります。

金融サービス会社がどれだけの財務データを生成するかは驚くべきことです...テストデータセットで気付かなかったのは、データの量が月末の手順を守れないことでした。「今月のデータ」を新しい試運転に置き換える前に削除するのに時間がかかりました。

MonthlyAllocationテーブルにすべて依存する「誰が何を知っているか」というカタログ化されていないリストを壊すことなく、処理を高速化するために何かをしなければなりませんでした。私は魔術師を演じ、その下からテーブルクロスを鞭打ちすることにしました。古い学校に行って、Partitioned Viewを使用しました。データにはすでにIsCompleteフラグが含まれていたため、2つのテーブルを作成しました。それぞれに逆のチェック制約があります：MonthlyAllocationComplete、MonthlyAllocationInComplete

次に、元のテーブルと同じ名前のMonthlyAllocationでパーティションビューを作成しました。データベースに対して行った物理的な変更について賢明なプロセスはありませんでした。報告書が破られることはなく、直接アクセスできるアナリストは、その「テーブル」の前後に問題を報告していません。

かっこいい話ですが、どこに行きますか？

そこに命名規則tbl_MonthlyAllocationがあった場合はどうなりますか？それで？組織内のすべてのETL、すべてのレポート、すべてのアドホックスプレッドシートを調べ、vw_MonthlyAllocationを使用するようにそれらを更新するのに多くの工数を費やしていますか？そしてもちろん、これらの変更はすべて変更委員会を通過し、それは常に迅速で簡単なプロセスです。

あなたは上司に尋ねるかもしれません：そのすべての仕事に対する会社への報酬は何ですか？

もう1つのオプションは、tbl_という名前のこのビューをそのままにして、コードのテスト、更新、およびデプロイに時間を費やすことはありません。これは、すべての新規採用者、およびオブジェクトの名前付けと矛盾する理由についてデータベースと連携する必要がある短い注意期間を持つ人に説明する面白い逸話になります

または、冗長なメタデータを使用してオブジェクトを二重エンコードしないでください。データベースは、テーブルとは何か、ビューとは何か、テーブル値関数とは何かなどを喜んで教えてくれます。

命名規則は良いものです。ただ、それらのコーナーに自分自身をペイントしないでください。

ここでブレント（あなたが質問で言及している人）。

テーブル名の前にtblを追加しないと言った理由は、子供の名前の前に子供を追加しないと言うのと同じ理由です。それらをchildJohnおよびchildJaneとは呼ばない。値を追加しないだけでなく、後年に子になることもありません。また、オブジェクトが後でビューになることもあります。

これは非常に主観的な議論ですが、ここに私の考えがあります：tblプレフィックスは無用です。

コードを見ているシナリオはいくつありますが、何かがテーブルなのか他の何かなのかわかりませんか？

Object Explorerでテーブルのリストを見るときに、探しているテーブルを見つけるためにさらに作業を行う必要があることを除いて、tblはどのような価値を追加しますか？

一部の人々は、テーブルまたはビューを処理しているときに、コードでそれを明確にしたいと言います。どうして？そして、これが重要な場合、なぜビューに特別な方法で名前を付けるだけではありませんか？ほとんどの場合、テーブルのように機能するため、区別する価値はほとんどありません。

それはひどい習慣です。

tbl
tbl_
Table_
t_

...それらをすべて実稼働で見ました。

現在作業している製品の1つには、という名前のテーブルtbl_whateverの半分と、「通常」という名前のテーブルがあります-明らかに、異なる標準に取り組んでいる開発者がいます。別の悪い習慣の1つは、外部キーである列名の先頭にを付けfk、fkその後にテーブル名、次に列名を付けて、などのひどい列名を与えることfktbl_AlarmsfkAlarmsIDです。その命名規則はtbl_%マントラ全体の単なる論理的な拡張であり、それがどれほどばかげているのかがわかります！

私は毎日私を泣かせる他のデータベースをほとんど忘れていました。カラム名...を前置データ型dtPaymentDateの名前が本当に必要なので、dtプレフィックスを？ `

prepTo adjThose adjOther nouPeopleを確認しないでください。proYou auxShould advAlways verUse nouPrefixes prepWith proYour adjTable nouNames。proI auxHave advEven verStarted gerProThem prepIn adjNormal nouWritingを使用します。

comAdvHow adjEffective proIt verI？nouPeople auxCan verProを理解するあなたのnouWriting adjBetter！

このようなプレフィックスを使用することは、ハンガリー記法として知られています。前提は簡単です。名前の付け方によって何かを判断できます。これは、プログラミング言語、特に開発者がスキルの欠如または言語機能の欠如により数十ページにわたるモノリシック機能を記述する場合に特に一般的です。これは、開発者がデータ型をまっすぐに保つのに役立つニーモニック支援です。

一般的に、この命名スタイルは、本当に古いコードで使用されているか、単に学習している（そしてたまたまこの習慣を学習している）開発者によって使用される可能性があります。私の経験では、ハンガリーの記法がプログラミングコースやチュートリアルで紹介されていない場合、経験の浅い開発者が自発的に登場することは比較的まれです。iまたはxまたはacctのような変数名を使用する可能性が高くなります。

隅に自分自身を描くことに加えて、これは本当に単なるフィラーです。SQL構文は十分に正確であるため、開発者は、フィールド、レコード、またはデータセット（テーブル、ビューなど）について話しているかどうかを常に知る必要があります。すばらしい教材になるかもしれませんが、この構文は通常、実稼働データベースには存在しないはずです。読みやすさを損なう可能性があり、特にtbl vs. table vs. tabなどのいくつかの代替命名テーマがポップアップする場合、探しているテーブルを見つけるのがより難しくなります。

データベースは、テーブル、フィールドなどと呼ばれるものを実際に気にしません。これらは、人間のオペレーターまたはスクリプトによって特定の順序で配置された単なるデータのバイトです。ただし、このデータを保持する必要のある人間は、「ユーザー」、「注文」、「アカウント」などの意味のある名前を高く評価します。「show table like 'a％'」などのSQLクエリを使用している場合も、より実用的です。プレフィックスとサフィックスを使用すると、ささいなメンテナンスが不必要に複雑になる可能性があります。

私のようないくつかのブログの記事を読んだ本や、これを私は私の最初のSQL Serverインスタンスを継承し、接頭辞、私はそれほど冗長アプローチと特異命名規則と新しいものの開発を開始したい多くのオブジェクトに気づいた後（（かなりの数があります）私にとっては（そしておそらく他の開発者も）オブジェクトリレーショナルマッピングに取り組むのがずっと簡単です）。

最も広く使用されている接頭辞の一つでしたTblかtbl、その後私は持っていたTBLとtbl_しても、*TableName*_Tbl

クエリを実行してVisual Studioから操作しようとすると、これは単なる地獄です。テーブルのセット全体にプレフィックスを付けても構いませんがtbl、少なくともデータベース全体ではそのままにしてください。

結局、個人的な好みの問題だと断言できますが、それは一貫性にも関係しているので、その道を進んでいくと、多くの人は少なくとも開発中は同じ状態を保っています。

...一方で、他のアプローチを取り、接頭辞のない単数形のテーブルに進むと、将来的に開発者を幸せにすることができますか？幸福よりも重要なことは何ですか？

はい、オブジェクトのタイプを示すプレフィックスを追加することは問題であり、不要です。なぜなら、

1. 時にはオブジェクトは何かとして人生を始めますが、何か他のものになってしまいます。（例えば、テーブルをtblXxx分けたtblXxxYとtblXxxZ何らかの理由で2つの新しいテーブルを結合するビューに置き換える。今、あなたが呼ばれるビューを持っていますtblXxx）。
2. あなたが入力するとtbl、エディタで、そのオートコンプリート機能が45秒間ハングして、あなたに4000個のエントリのリストが表示されます。

しかし...

私は悪魔の擁護者を演じ、他の人が断固として助言したことを言うつもりです。接尾辞/接頭辞が役立つ可能性のあるまれなケースがいくつかあります。ここに私が働いている組織の例を示します。

エンティティベースのERPシステムがあり、ビジネスロジックはOracle PL / SQLで記述されています。20年近く前ですが、非常に安定したシステムです（これはレガシーシステムではありません。継続的に開発しています）。

システムはエンティティベースであり、各エンティティはテーブル、複数のビュー、複数のPL / SQLパッケージ、および他のデータベースオブジェクトのホストを関連付けます。

ここで、同じエンティティに属するオブジェクトには同じ名前を付けるが、その目的とタイプを区別できるようにする必要があります。だから、我々は命名されている2つのエンティティを持っている場合CustomerOrderとCustomerInvoice、我々は次のオブジェクトがあります：

1. データを保存するテーブル[ TABサフィックス]：
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB。
2. クライアントが使用するビュー[接尾辞なし]：
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE。
3. 基本操作のインターフェース。（PL / SQLパッケージ）[ API接尾辞]：
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API。
4. レポートジェネレーター。（PL / SQLパッケージ）[ RPI接尾辞]：
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI。
5. 主キーのインデックス[ PKサフィックス]：
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK。
6. セカンダリインデックス[ IX接尾辞]：
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX（ここXXXで、インデックスの使用法を説明します）。
7. ... 等々。

これは実際、Apps Hungarianの形式です（同じタイプのオブジェクトは、目的に応じて異なる接尾辞を持つことができることに注意してください）。ただし、プレフィックスの代わりにサフィックスを使用します。このシステムの読みやすさを十分に説明することはできません。IntelliSenseが実際に機能するのはTBL、4000個の結果を入力して取得する代わりに、Customerという名前のエンティティに属するすべてのオブジェクトを入力して取得できるためCustomer*です。

そこで、ここでメタデータがどのように役立つかを示しました。目的は、単一の名前で識別可能な関連するデータベースオブジェクトのセットを持ち、目的に基づいてそれらを区別することです。

そうは言っても、この種のシステムがない場合、オブジェクトのタイプの前置または後置の使用はありません。

我々のような接尾辞を使用していないことに注意してください_table、_packageまたは_view（つまりタイプオブジェクトの）。たとえば、（3）と（4）は両方ともPL / SQLパッケージですが、異なる接尾辞を使用します。（5）と（6）でも同じです。どちらもインデックスです。したがって、接尾辞はタイプではなく目的に基づいています。

tl; drこれは（非常に可能性が高い）冗長な情報を追加し、認知のオーバーヘッドにつながるため、削除する必要があります。

特にコンピュータシステムでは、コンテキストは素晴らしいものです。コンテキスト外でusersは、呼び出されたものがテーブル、ビュー、ストアドプロシージャ、または他の何かであるかどうかを判断できない可能性があります。レガシー（または単に不適切に記述された）システムおよび言語は、多くの場合、コードの読み取り中にコンテキストを解決することを困難にします。たとえば、Bashでは、少なくとも関数の内容を読み取らないと、何をするのかわかりfunction usersません。Javaでは、かなり透明であり、詳細を簡単に掘り下げることができます。Map<Uid,UserDetails> users()

この引数をSQLテーブルに使用すると、それがusersテーブルであるかビューであるかを消費者が知るのに役立つのはいつですか？言い換えれば、されるtblプレフィックスは、消費者のいずれかに彼らが知らない何かを言うつもりと知っておく必要がありますか？願わくば、大多数の消費者がそれに対してDMLおよびDQLクエリを書くことを願っています。彼らにとっては、それは単なる別のデータソースである必要があり、それがビューであるかテーブルであるかは、パーティション分割されているか、HDDやSSDに保存されているか、その他の技術的詳細とほぼ同じである必要があります。もちろん、DBAはまれなDDL / DCLクエリを実行するためにこれらの詳細を知る必要がありますが、スキーマをナビゲートしてすべての技術的な詳細を取得する方法を本当に知っている少数派のために名前空間を汚染することは逆効果のようです。

リレーショナルデータベース管理システムの機能の1つは、物理ストレージからクライアントへの情報の論理的な表示を分離することです。前者は行セットの列です。後者は、ストレージボリューム上のファイルです。一方を他方にマップすることはDBMSの仕事です。どのハードウェアが情報のニーズをサポートしているのかは、DBAまたはシステム管理者のみが懸念します。消費者はこれらの懸念に気付く必要はありません、実際にそうすべきではありません。

クライアントは、行セットがどのように構築されるかについても心配する必要はありません。この点で、ベーステーブル、ビュー、または関数はすべて同一です。それぞれは、クライアントが消費する行と列のセットを単に生成します。単純なスカラーでも、1行1列のテーブルと見なすことができます。行/列モデルは、クライアントとサーバー間の契約です。

アーティファクトの名前の前に実装タイプを付けることにより、この懸念の分離が壊れます。これで、クライアントはサーバーの内部を認識し、依存します。サーバーのコーディングの変更には、クライアントの再作業が必要になる場合があります。

ここには多くの回答がありますが、これは非常に価値のある命名規則ではないことを示しています。他の答えに納得していない人々のために、私は他の多くの答えが言っていることを実証しようとします。

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

上記のステートメントでは、という名前の列から3つの列を選択していますdbo.foo。プレフィックスの主な不満の1つdbo.fooは、テーブルかビューかを知らないことです。もちろん、それは抽象化としての見方の長所の1つですが、私は脱線します。彼らはこのようにオブジェクトにプレフィックスを付けるべきだと言っていますdbo.tblFoo。これで、上記のクエリでオブジェクトが（おそらく）テーブルであることがわかります。ただし、その目標と機能的に同等なものを作成すると、次のようになります。

SELECT
  bar
  , fizz
  , buzz
FROM dbo.Foo --table

プレフィックスが効果的に主張しているのに、コメントは役に立たないと思われます。役に立たないノイズを強調するために、このメタデータコメントインジェクトは、より複雑なクエリを検討します。

SELECT
  qc.occurances
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Indexed view*/ qc WITH (NOEXPAND)
  INNER JOIN dbo.interviewer /*partitioned view*/ i ON i.employeeId = qc.interviewerId
  INNER JOIN dbo.question /*table*/ q ON q.id = qc.questionId
WHERE
  EXISTS (
           SELECT 
             1 
           FROM dbo.currentEmployees /*view*/ ce 
             INNER JOIN dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           WHERE
             ce.employeeId = i.employeeId
             AND
             qa.questionId = q.id
         )
  AND
  qc.occurances > 5;

余分なコメントは、そのクエリを推論しやすくするのですか、それとも余分なノイズを追加するだけですか？私の意見では、彼らは余分なノイズを追加し、ゼロ値を追加するだけです。それが反接頭語が言おうとしていることです。さらに、データモデルを調整する必要がある場合、コメントを更新するコストはプレフィックス付きテーブルの名前を更新するよりもはるかに低いため、実際にはプレフィックスを使用する方がそれらのコメントよりも悪いです。これらのプレフィックスにはコストがかかり、貴重な情報を伝えないため、避ける必要があります。

一部の人々が引用するプレフィックスの別の利点は、開発環境で何らかのグループ化または順序付けを与えることができることです。コードの編集に多くの時間を費やしているため、これは一部の人にとっては魅力的な議論になり得ます。しかし、私の経験では、現代の開発環境は同等または優れたオプションを提供し、コードに無駄なメタデータを散らかさず、柔軟性を制限しません。

これは何度も取り上げられてきましたが、おそらく最も有名なのは、アメリカのSQLおよびリレーショナルデータベースのエキスパートであるJoe Celkoです。私は個人的にオンラインで彼の暴言の1つを受け取っています（光栄に感じています）。彼はこれらの接頭辞を「せせらぎ」、またはより正確には「スキューモーフィズム」と表現しています。

一般的な考え方は、これらのプレフィックスは昔からのコーディング慣行であり（おそらくオブジェクト名の8バイト制限などの命名制限による）、明らかに有用な理由もなく、単なる「方法」以外の世代のプログラマーに受け継がれているされております"。

企業、ブロガー、およびプログラマーは、独自のコーディングスタイルで情報を渡します。一部のスタイルは、他のスタイルよりも少し「フランケンシュタイン」かもしれません。会社には「ハウススタイル」があり、プログラマーはこのプラクティスを学ぶことを余儀なくされます。

時間が経つにつれて、元々使用されていた理由が非推奨になったとしても、物事は固執します。「Tibbling」は、リレーショナルデータベース管理で最もよく知られている例の1つです。

切り上げると、値は追加されず、各テーブル名に正確に4バイトのストレージスペースが追加されます。現代のSQL Serverシステムには何も提供しませんが、そこにいる方が気分が良くなる場合は、先に進んで使用してください。

私の提案は、これをすぐにやめることです。これにより今後不快になる場合は、テーブル名の最後に「_tbl」を追加してください。もちろん、すでに述べた理由から、それを行う必要もありません。最初にそうするようにあなたに言った人はあなたにいくつかの悪いアドバイスを与えました。「これは私たちの組織のシステムのセットアップが不適切であるという意味では理にかなっています」というアドバイスは悪いかもしれませんが、その場合はそれを修正するのが彼の仕事でした。まだ悪いアドバイス。

「テーブルの前にtblを付けないでください」は本当に問題ですか？

システムについて？いいえ。他の人についてですか？多分。lotsa hateを生成できます。

私は個人的にテーブルにプレフィックスを付けませんが、ビュー、ストアドプロシージャ、関数などの他のオブジェクトにはプレフィックスを付けます。

これをやめてください。それは過去に起こりましたが、これを続けることで、あなたの環境に入ってくる新しい人々に、それが地域の慣習であると考えて継続することを奨励します。しかし、彼らはただ続けるのではなく、わずかに異なる方法でそれをします

特定のアイテムのdbをトロールするとき、オブジェクトエクスプローラーを開いてスクロールするのは私だけではないので、アルファベット順であることがわかります。それは接頭辞が水の濁りを開始し、tblname、tbl_name、tbname、t_name、および他の数千のバリエーションがあるまで、すでにテーブルであることがわかっているテーブルを見つけるのは本当に難しくなります

同様に、すべてのvw_またはsp_のプレフィックスを付けると、誰かが入り、SPname、spname、s_p_nameを取得します。すべてのプレフィックスを削除すると、ソフトウェアはアイテムが何であるかを認識します。本当に必要な場合は、代わりにサフィックスを使用します。NameOfMyView_v、NameOfMyProc_sp。視覚的に簡単に検索できます

しかし、長いストアドプロシージャをトロールしていて、ビューがプロシージャまたはテーブルであるものを簡単に判断できない場合はどうでしょうか。とにかく、これらがエイリアスされる可能性があり、そうでない場合でも接尾辞があなたの助けになります

自分のすることを変更することを恐れないでください。命名規則がすでに完全に打ち出されている環境に足を踏み入れたとしても、自分で実装することを恐れず、より良い方向に物事を変え始めてください。既存のカオスと一致させることで、混乱を減らすことはできず、さらに混乱させるだけです。

プレフィックス 'tbl'の利点を考えなければならない場合、現在のSSMSでは、インテリセンスを使用して、次のように入力できます。

select * from tbl

次に、必要なテーブル名を見つけます（正確なテーブル名がわからない場合）。これはワンステップ作業です。もちろん、我々は常に、追加の工程を経て、テーブル名を見つけることができますが、私は「TBL」プレフィックスで、これがあると言うだろうONEステップの仕事、と私はいつも（必ずしも「TBL」）における接頭辞を好む理由です私の宿題プロジェクト。

編集：（非常に多くの反対票を投じた後、SQLサーバーの特定のカテゴリのオブジェクトに特定のプレフィックスを付けることのニッチな利点を指摘する価値はまだあると思います）。ストアドプロシージャ/関数/ビューの接頭辞を持っていると文句を言う人はいないようですが、テーブルを使用した接頭辞については常に議論があります。（私にとって、現実の世界では、テーブルにプレフィックスを付けるかどうかはあまり気にしません）。

2005年のsqlサーバーでは、どのストアドプロシージャ/ビューでどのテーブルが使用されているかを検索する必要がありました。（はい、私は他の方法があったことを知っています、ここで議論はありません）。

私のキャリアは多くの「ベストプラクティス」の論文/記事を読むことで成長しますが、さまざまなシナリオでほぼすべての「ベストプラクティス」に対する何らかの例外を十分に見ています。したがって、私は常に自分自身と同僚のDBAに、ビジネス要件に応じて判断を下し、「ベストプラクティス」は確かに適切であると伝えますが、それは私たち自身の環境のコンテキストでのみ考慮することができます。

dbo.User対を検討してくださいdbo.tUser。ここで、このテーブルが使用されているコード内のすべての場所を検索するとします。どのバージョンでこれが簡単になりますか（または可能になりますか？）、「ユーザー」という単語には、変数名、コメントなどに多くの誤検知がある可能性があります。

それは私が他のどの答えにも見たことのないものですが、私は開発者兼DBAなので、おそらく他の人はクエリをアプリケーションに埋め込むことができるレガシーコードで作業する必要がなかったかもしれませんクエリは、スキーマを使用して参照を完全に修飾します。（すべてが完全に修飾されていてdbo.Userも[dbo].[User]、dbo.[User]などを見つける必要があります）。または、「依存情報」が古くなって不正確なデータベースバージョン（MS-SQLの古いバージョンなど）

そのため、私が取り組んだいくつかのプロジェクトでは、そのように混在しているため、単により選択的な検索用語にするために、tor vプレフィックス（tbl_はバカになります）を義務付けました。

SQL Server Data Tools（hello、すべての参照の検索）、ORMレイヤーのみを使用したデータベースアクセスなどの後のプロジェクトでは、テーブルのすべての使用を見つけるのは簡単です（名前を変更しているように！）

どちらの面にも長所と短所があります。従うべき規則を決定するのは、チームまたは会社のリード次第です。

私たちは、1つには、このtbl規則を使用します。主な理由は、スクリプトでできることとすべきでないことを知っているからです。スキーマを暗記せずに飛び込むさまざまなプロジェクトや人々がいます。テーブルには論理名があるため、スクリプトを記述しているときに簡単に見つけられます。その間、テーブルを見つけると、テーブルであることを（IntelliSenseを介して）すぐにわかります。プレフィックスを追加しても、コンテキストはあまり追加されないと主張できます。ただし、これを削除すると、コンテキストがなくなります。

プレフィックスを使用しない唯一の本当の利点は、互換性です。ただし、これは潜在的に危険な状況であると主張します。確かに、スクリプトとクエリは壊れませんが、その事実に頼りすぎているかもしれませんが、ビューで機能しないものや不適切なものもあります。

最終的には、チームが好むものと、コード/スクリプトの記述方法に要約されます。

以前は、テーブル名の前に「tbl」を付ける理由がありました。データベースオブジェクトのリストを見ている場合、次のクエリを実行できます。

select * from sysobjects

テーブルのみを取得したい場合、これを行うことができます：

select * from sysobjects where type = 'U'

誰がそれを覚えていますか？テーブル名がすべて「tbl」で始まる場合、次のクエリを使用できます。このクエリでは、type列の値を記憶する必要はありません。

select * from sysobjects where name like 'tbl%'

SQL Server 2014にタグを付けたので、これは適用されません。SQLServer 2005以降、代わりにこれを実行できるためです。

select * from sys.tables

テーブル名にプレフィックスを付ける別の理由は考えられません。