web-dev-qa-db-ja.com

テーブル名に「tbl」プレフィックスを追加することは本当に問題ですか？

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

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

質問と考慮事項

  • これは本当に問題ですか？最初のdbaジョブ以降、テーブルに「tbl」をプレフィックスとして付けているためです（上級DBAが組織のためにそれを行うように指示しました）。
  • これは私が取り除く必要があるものですか？私はいくつかのテストを行い、非常に大きなテーブルをコピーして 'tbl'プレフィックスを付け、他のテーブルはそれを付けずに、パフォーマンスの問題に気づきませんでした。
sql-serverbest-practicesnaming-convention
94
Racer SQL

私はかつてテーブルを持っていて、それはピカピカで美しかったです。組織のすべての財務トランザクションを保持していました。その後、データの読み込みを開始しました。

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

金融サービス会社が生成する金融データの量は驚くべきものです...テストデータセットでわかっていなかったことの1つは、データの量が月末の手順に対応できなくなることでした。新しい試用版に置き換える前に、「当月のデータ」を削除するのにますます長い時間がかかりました。

すべてがMonthlyAllocationテーブルに依存する「誰が何を知っているか」のカタログされていないリストを壊すことなく、処理を高速化するために何かをする必要がありました。私は魔術師を演じ、テーブルクロスを下からむち打ちすることにしました。私はオールドスクールに行き、 分割ビュー を使用しました。データには既にIsCompleteフラグが設定されているため、2つのテーブルを作成しました。それぞれに逆のチェック制約があります：MonthlyAllocationComplete、MonthlyAllocationInComplete

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

クールな仲間ですが、どこへ行きますか？

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

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

もう1つのオプションは、このビューの名前をtbl_のままにして、コードのテスト、更新、展開にその時間を費やすことはないということです。オブジェクトの名前付けに一貫性がない理由についてデータベースと連携しなければならない、すべての新入社員、および注目期間が短い社員に説明するのは、面白い逸話になります。

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

命名規則は適切です。ただ、それらに慣れてはいけません。

215
billinkc

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

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

133
Brent Ozar

これは非常に主観的な議論ですが、私の見解は次のとおりです。tblプレフィックスは無用です。

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

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

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

118
Aaron Bertrand

それはひどい習慣です。

tbl
tbl_
Table_
t_

...それらすべてが生産されているのを見ました。

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

私は日常的に泣く他のデータベースをほとんど忘れていました。列名にプレフィックスを付けるデータ型... dtPaymentDate、名前にdtプレフィックスが本当に必要なため？ `

42
Philᵀᴹ

comPon't verprepen prepTo adjThose adjOther nouPeople。 proYou auxShould advAlways verUse nouPrefixes prepWith proYour adjTable nouNames。 proI auxHave advEven verStarted gerUsing proThem prepIn adjNormal nouWriting。

comSee advHow adjEffective proIt verIs？ nouPeople auxCan verProUnderWriting adjBetterを理解してください！

25
ErikE

このような接頭辞の使用は ハンガリー語表記 として知られています。前提は単純です。名前がどのようになっているかによって、何かを判別できます。これは特にプログラミング言語で一般的です。特に、開発者がスキルの欠如または言語機能の欠如により、数十ページにまたがるモノリシック関数を作成する場合によく見られます。これは、開発者がデータ型を正確に保つのに役立つニーモニック補助です。

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

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

データベースは、テーブル、フィールドなどを何と呼んでも構いません。これらは、特定の順序で配列された単なるデータのバイトです。彼らの人間のオペレーターやスクリプト。ただし、このデータを保持する必要がある人間は、「ユーザー」、「注文」、「アカウント」などの意味のある名前を理解します。 「show a like 'a％'」のようにSQLクエリを使用している場合も、より実用的です。接頭辞と接尾辞を使用すると、さもなければささいな保守を不必要に複雑にする可能性があります。

21
phyrfox

最初のSQL Serverインスタンスを継承し、接頭辞の付いた多くのオブジェクトに気付いた後、 this または this （かなりの数があります）のようないくつかのブログ投稿を読みました。より簡潔なアプローチと単一の命名規則で新しいものの開発を開始します（[と他の開発者]がオブジェクトリレーショナルマッピングで作業する方がずっと簡単です）。

最も広く使用されている接頭辞の1つはTblまたはtblでしたが、TBLとtbl_および*TableName*_Tbl

enter image description here

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

結局、私は個人的な好みの問題だと間違いなく言いますが、それは一貫性にも大きく関係しており、その道を進んだ場合、多くの人々は少なくともあなたの開発に沿ってそれを同じに保つことで幸せになります。

...一方、私が言いたかったのは、他のアプローチをとり、接頭辞なしの単数形の名前のテーブルを使用する場合、将来的に開発者を幸せにするでしょう。幸福よりも何が重要ですか？

12
Nelz

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

  1. 時々、オブジェクトは何かとして生命を開始しますが、 最終的に別のものになる になります。 （たとえば、テーブルtblXxxは、何らかの理由でtblXxxYとtblXxxZに分割され、2つの新しいテーブルを結合するビューに置き換えられました。これで、tblXxx）。
  2. エディターでtblと入力すると、そのオートコンプリート機能が45秒間ハングし、4000エントリのリストが表示されます。

だが...

私は悪魔の擁護者を演じて、他の人が完全に反対してアドバイスしたことを言います。いくつかのまれなケースがあり、サフィックス/プレフィックスが役立つ場合があります。これが私が働いている組織の例です。

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

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

ここで、同じエンティティに属するオブジェクトには同じ名前を付けますが、その目的とタイプを区別できるようにします。したがって、CustomerOrderおよびCustomerInvoiceという名前の2つのエンティティがある場合、次のオブジェクトが作成されます。

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

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

そこで、ここではメタデータがどのように役立つかを示しました。目的は単一の名前で識別可能な関連する一連のデータベースオブジェクトを作成し、目的に応じて区別するです。

そうは言っても、この種類のシステムがない場合、オブジェクトのtypeの接頭辞または接尾辞を使用することはできません。

_table、_package、または_view（つまり、オブジェクトのtype）などのサフィックスを使用していないことに注意してください。たとえば、（3）と（4）はどちらもPL/SQLパッケージですが、異なるサフィックスを使用しています。 （5）と（6）も同じで、どちらもインデックスです。したがって、サフィックスはtypeではなくpurposeに基づいています。

11
sampathsris

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

Contextは、特にコンピュータシステムでは素晴らしいことです。コンテキスト外では、usersと呼ばれるものが、テーブル、ビュー、ストアドプロシージャ、その他のどれであるかを完全に区別することはできませんでした。レガシー（または単にひどく書かれた）システムと言語は、コードを読んでいる間、コンテキストを理解するのを難しくします。たとえば、Bashでは、関数の内容を読み取る少なくともせずに_function users_が何をするかを知ることはできません。 Javaでは、Map<Uid,UserDetails> users()はかなり透過的で、詳細まで簡単に掘り下げることができます。

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

10
l0b0

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

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

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

9
Michael Green

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

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

上記のステートメントでは、dbo.fooという名前から3つの列を選択しています。プリフィックスの主な不満の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;

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

一部の人々が引用する接頭辞のもう1つの利点は、開発環境にある種のグループ化または順序付けを付与できることです。コードの編集に多くの時間を費やしているため、これは一部の人にとって魅力的な議論になる可能性があります。ただし、私の経験では、現代の開発環境は同等またはより優れたオプションを提供しており、無用なメタデータでコードを散らかしたり、柔軟性を制限したりしません。

8
Erik

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

一般的な考え方は、これらの接頭辞はずっと昔からのコーディング慣行であり（おそらくオブジェクト名の8バイトの制限などの名前付けの制限による）、プログラマーの世代を明らかに有用な理由なしに受け継いだということです。されております"。

企業、ブロガー、プログラマーは、独自のコーディングスタイルで情報を伝えます。一部のスタイルは、他のスタイルよりも「フランケンシュタイン」のほうが多いかもしれません。会社には「家のスタイル」があり、プログラマーはこの慣習を学ぶ必要があります。

時間の経過とともに、元々使用されていた理由が廃止されたとしても、現在は非推奨です。 「ティブリング」は、リレーショナルデータベース管理で最もよく知られている例の1つです。

まとめると、値は追加されず、そこにあるという理由以外の理由なしに、各テーブル名に正確に4バイトのストレージスペースが追加されます。最新のSQL Serverシステムには何のメリットもありませんが、そこにそれを持っている方が良いと感じる場合は、先に進んでそれを使用してください。

7
John Bell

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

5
user3131341

「テーブルにtblをプレフィックスしないでください」は本当に問題ですか？

システムについては？いいえ。他の人に関しては？多分。あなたはくじ引きを生成することができます。

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

3
Joe

これをやめてくださいと言わざるを得ません。それは過去に起こったことですが、これを続けることで、あなたの環境にやって来た新しい人々にそれを地元の慣習だと思って継続するように勧めます。しかし、彼らは継続するだけではなく、少し異なる方法でそれを行います

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

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

しかし、長いストアドプロシージャをトロールしているときに、ビューまたはプロシージャまたはテーブルが何であるかを簡単に判断できない場合はどうでしょうか。とにかく、これらのエイリアスはエイリアスとなる可能性が高く、サフィックスが付いていない場合でも役立ちます

自分の作業を変更することを恐れないでください。名前付け規則がすでに変更されている環境に足を踏み入れた場合でも、独自のものを実装することを恐れず、より良いものに変更し始めてください。既存のカオスを一致させることにより、混乱を少なくする可能性はなく、より混乱させるだけです

1
cockbeard