これは、同じスクリプトの異なるインストールを互いに区別するためによく使用されます。たとえば、サーバー上のコンテンツが異なる2つのJoomlaインストールがあり、MySQLデータベースは1つだけであるとします。
明らかな理由により、両方のJoomlaインストールは同じデータベーステーブルを共有できません。これは、両方のインストールが同じコンテンツを表示するためです。そして、それが接頭辞が発動する場所です。
異なるテーブルプレフィックスを使用することで、Joomla Installation＃1にプレフィックスJOS_のすべてのテーブルを使用することになっていることを通知でき、Joomla Installation＃2はプレフィックスJOS2_のすべてのテーブルを使用する必要があります
Tblまたはtbl_（例：tbl_MyTableまたはtblMyTable）を支持する人もいれば、MyTable_Tなどの接尾辞を付ける人もいます。
個人的に私は接頭辞/接尾辞を避けます。スキーマが時間の経過とともに変化する場合、テーブルの代わりにビューで置き換えることができるため、2つのタイプのオブジェクトを実際には区別しません。
最も重要なことは、チーム内で命名ガイドラインを文書化し、一貫性を保つためにすべて同じガイドラインセットに従うことです。
テーブルにはプレフィックスは不要です。
これは純粋にあなた次第です。
ただし、より簡単にテーブルをグループ化するために、テーブルが属するアプリケーションのモジュールに関連するテーブルのプレフィックスを付けます。
テーブルのプレフィックスは、追加のセキュリティ対策としても役立ちます。たとえば、テーブルプレフィックスを追加すると、一般的なテーブル名が不明瞭になり、ハッカーがSQLインジェクションまたはその他のセキュリティホールを介してデータベース内のデータにアクセスすることが難しくなります。
ただし、テーブルのプレフィックスをセキュリティの唯一の方法としてではなく、単なるセキュリティの別のレイヤーとして見てください。 SQLインジェクションやその他の同様の脅威を防ぐために、他のセキュリティ対策を講じる必要があります。たとえば、コードの設定方法によっては、ハッカーがSQLインジェクションを介して「show tables」コマンドを実行し、データベーステーブルの名前を取得することも可能です。
奇妙なことに、テーブルプレフィックスを使用して、通常予約されているキーワードをテーブル名として使用できることも言及されていません。
例えば。 t_userまたはt_orderが可能になりました。
Webサイトとデータベースの構造が複雑な場合、テーブルのプレフィックスを使用すると、データベースでの名前の競合を防ぐことができます。
次のような状況では、テーブルプレフィックスがよく表示されます。
複数のスクリプトが1つのWebサイトに統合されており、完成したWebサイトでデータを共有する必要がありますが、各スクリプトに固有のプレフィックスがないとテーブル名が競合します。
取得したスクリプトに機能を追加しており、そのスクリプトに固有のテーブルと手動で作成している新しいテーブルを区別したい。そのようにして、新しいテーブルを作成した場合、異なるテーブルプレフィックスがあるため、ベーススクリプトへの今後の更新と競合しません。
1つのデータベースのみを提供するホスティングプランがあり、そのデータベースを使用して複数のスクリプトを処理する場合。 （これはさまざまな理由で推奨されませんが、ユーザーがこれを行うのを見てきました。）
スクリプトをゼロから作成する場合、データベース構造のすべての側面を制御するため、通常、テーブルプレフィックスは必要ありません。複数のスクリプトの統合を開始すると、便利になり、場合によっては必要になります。データベース内の名前の競合を心配することなく、複数のスクリプト間で一意のデータビューを作成し、テーブルなどを結合できます。
命名規則に応じて、テーブルとビューを区別すると役立つ場合があります。
欠点は、テーブルの名前に関する限り制限される可能性があることです。 Oracleでは、これに30文字の制限があります。 「Tbl_」をプレフィックスとして使用すると、自動的に4文字が失われます。それは問題かもしれません。