database-design - システムテーブル/ビューとの関係はありますか？

Question

ユーザーテーブルからシステムへの関係を持つことは可能ですか？テーブル見る？コンテキストを与えるために、あるテーブルの列の値を別のテーブルの列名に制限したいと思います。これは、2番目のテーブルの列名を格納するシステムビューを確認することで最も簡単に実行できるようです。テーブル。

したがって、古典的な例を使用して、Customers（FirstName LastName）のテーブルがある場合、「FirstName」または「LastName」のみである列「customerAttribute」を持つ別のテーブルを作成したいと思います。これを動的に保つには、「customerAttribute」列が実際には、Customerテーブルの列の名前を格納するシステムビューからの外部キーであると便利です。そうすれば、実際のCustomersテーブルで列が追加、削除、および名前変更されるときに、データの整合性の問題について心配する必要がありません。

SQL Serverでこの関係を作成する簡単な方法がわかりませんでした。そのため、システムテーブルやビューとの関係をいじったり、作成したりするのは大したことではないかと思います。

ありがとう！

PS私は、SOに投稿した別の問題を解決するために、この質問をします。

編集：システムビューと直接関係を作成できない場合でも、クエリをシステムビューに返し（列名を取得するため）、そのビューとの関係を作成するビューを作成できます...今それを試してみてください。

Answer 1

システムテーブルの列を参照するユーザーテーブルの列を作成することを妨げるものは何もありません。したがって、明白な答えはイエスです。実際の質問に答えるには、別の質問をする必要があります。つまり、メタデータをユーザーテーブルに保存するのは良い考えですか。

データ管理の純粋主義者の観点から答えるとしたら、これはほとんどの場合悪い考えだと思います。しかし、実際問題として、私はそれを誇りに思っていなくても、それをしました。データとメタデータをブレンドすることで得られる結果がいくつかありますが、それらをブレンドしないと達成することはほぼ不可能です。

実行するリスクは、最終的には、対象分野の専門家にとって意味のある属性に関して文書化できないデータベースになってしまうことです。言い換えれば、あなたのデータベースはあなた自身とあなたの仲間のオタクだけが使用できるようになります。時にはそれは許容できるリスクです。そうでない場合もあります。

Answer 2

MSは警告なしにシステムテーブルを変更できるため、システムテーブルに依存関係を持つことは常に悪い考えです。移植性があり、メタデータをクエリする必要のあるアプリケーションをサポートすることを目的とした情報スキーマビューを使用してみませんか？

Answer 3

それが可能かどうかはわかりませんが、可能であれば、あなたは確かに危険な地面を踏んでいます...どのように列の名前を変更しますか？列をどのように移動しますか？どのように列を削除しますか？この種のことは、おそらくSSMS内で多くのことを壊してしまうでしょう。このタイプのものは、トリガーまたはコードロジックでより適切に処理されます。