私たちの企業標準の1つは、ユーザーテーブル/インデックス用に個別のファイルグループ/ファイルを用意することです。これはデフォルトとして設定されているため、CREATE TABLEステートメントを修飾する必要はありません。
だからこんな感じ
なぜこれが義務付けられたのか、元の正当性を理解するのを手伝ってくれる人はいますか？
私はそれがブードゥー教だと思う状態できれいに来ます。私は間違っていますか...？
編集：インデックス/パーティション/アーカイブを分離するためにファイルグループを使用する方法と、断片的に復元する方法を知っています。この質問は、システムテーブル専用の同じボリューム上の別のファイルグループの使用についてです。
回答:
Microsoftの70-432トレーニングブックには、「プライマリファイルグループにオブジェクトを配置しない主な理由は、I / Oをできるだけ分離するためです。システムオブジェクトのデータは、データほど頻繁には変更されません。オブジェクト内にあります。プライマリデータファイルへの書き込みアクティビティを最小限に抑えることで、ハードウェア障害による破損の可能性を低減します。さらに、プライマリファイルグループの状態によってデータベースの状態も決まるため、可用性を高めることができます。データベースのプライマリファイルグループに加えられた変更を最小限に抑えます。」
だから、あなたがそうするようにそれを取りなさい。他の人は、これは特定の状況では必要なく、もちろん維持する方がよいと言います。私はマイクロソフトの推論を提供すると思いました。
これはパフォーマンスの向上ではありませんが、回復可能なゲインがあります。システムテーブルでファイルの破損が発生した場合、データベースは失われます。ユーザーデータを別のファイルグループ（または複数のグループ）に保持している場合は、復元中にデータベースの残りの部分をオンラインに維持したまま、それらのファイルのみを復元できます（ここではEnterprise Editionを想定しています）。
これが彼らがこれを述べている理由である場合、私は言うことはできませんが、これは、PRIMARYファイルグループ内のシステムオブジェクトのみを含む複数のファイルグループを持つことの利点です。
ただし、AutoShrinkを有効にする必要があると言ってジャンクを蹴る必要があります。
よくわかりませんが、あなたの会社の基準を正当化する人を求めていますか？あなたの会社の標準化文書を書いた人なら誰でも、なぜこれが行われるのかについてある程度の光を当てることができると思います。
とはいえ、システムデータをユーザーデータから分解したいと考える店も珍しくありません。また、ディスクの専用セットと組み合わせて使用すると、パフォーマンスが向上する可能性があります。