関係テーブルは本当に必要ですか？

Question

リレーションシップテーブルには、ほとんどの場合、2つの列、IDTABLE1およびIDTABLE2が含まれています。

リレーションシップテーブルの間で変更されるようなものは、これらの2つの列の名前とテーブル名だけです。
TABLE_NAME、IDTABLE1、IDTABLE2、そしてすべての関係のために、この表を使用します。私たちは一つのテーブルRelationshipsを作成し、この表では、我々は3つの列を配置する場合

それが良いでしょうか？

ウェブ/デスクトップアプリケーション開発では、これは良い/許容可能なソリューションですか？これには何が欠点でしょうか？

注：
フィードバックありがとうございます。それは有り難いです。
しかし、私はあなたがそれを少し遠すぎると思っています...すべての解決策は1つのポイントまで動作します。
データ保存のシンプルなテキストファイルは、MS AccessよりもExcelよりも優れています...
正直言って、私はこの解決策がなぜ小規模なプロジェクト（数GBのDBサイズ）で悪い

Answer 1

悪い考え。

IDTABLE1に任意のテーブルからのidが含まれている場合、どのように外部キーを適用しますか？

無関係の行を完全に無関係にするために不要なIOをロードせずに許容できるパフォーマンスを達成するには、先頭の列TABLE_NAMEを持つコンポジットインデックスが必要になります。

明らかに、この疑似パーティショニングを行っても、各行のテーブル名を繰り返すだけで、テーブル/インデックスに多くのスペースが無駄になります。

Answer 2

テーブルの怪物です。それはまた面倒です。パフォーマンス面では、このような表は素晴らしい考えではありません。また、そのようなテーブルに外部キーを追加することもできません。私は本当にそのような解決策に多くの利点を見ることができません。

Answer 3

2つのIDフィールドを保存するだけでは大したことではありませんか？ StudentID & CourseIDを持っていますが、EnrollmentDateではない、StudentCourse（またはそれ以上の登録）テーブルがある場合は、クラスの最初の日にすべての生徒が登録されているわけではありません。ほとんどのレコードがnullになる、すでに膨れたテーブルにこの列を追加するのは悪い考えです。

単一のテーブルの利点は、ユーザー/管理者がデータとの関係を作成できるようにするための要件である可能性があります（単一の参照または参照リストテーブルと同様）これらのUser Created Referencesに対処するためのテーブル。ダイナミッククエリを必要とする場合も同様です。このような動的データ構造要件を必要とするアプリケーションは、スキーマレスまたはnosqlデータベースに適しています。