データベースデザイン、複数のM-Mテーブル、または1つだけ？

Question

今日は私の個人的なプロジェクトのためのデータベースを設計していました。私はよりよい選択肢が決まることができなかったので、私は先生のデータベースに尋ねました。残念ながら、2つの選択肢のどちらが他の選択肢より優れているのか、その理由を教えてくれませんでした。

私はダミーデータジェネレータのためのデータベースを設計しました。多言語データを生成したいので、私はこれらのテーブルを考えました。 （しかし、そのテーブルの単純化）。

（最初と最後）名：ID、名前
街：ID、名前
言語：ID、名前

各names.nameとstreets.name言語に由来します時々、名前は複数の起源を持つことができます（例：Nickは英語名としてオランダ語です）。
各言語には複数の名前と通りがあります。

これらの2つのルールは、多対多の関係になります。現時点で私は2つのテーブルしか持っていませんが、私はこの種のテーブルのうち10と20の間に入るでしょう。
これを行う通常の方法は、10対20の多対多関係表を作成することです。
私が思いついたもう一つのアイデアは、IDと関連するテーブルを指定する3列目の多対多テーブルでした。

現時点では他のPCにデザインがあるので、夕食（2時間程度）後に私のアイデアを視覚化して更新します。

どのアイデアが優れているのですか？その理由は何ですか？

---

プロジェクトのアイデアビットより明確にするには、次の
常にプロジェクトのために良いと十分なリアルな作業データを作成するために面倒です。このアプリケーションでは、このデータが生成され、必要なSQLが返され、クエリを実行するだけで済みます。

ユーザーがサイトにアクセスしてデータを取得します。彼はテーブル名、自分れる列を述べ、その後、彼は、データの種類にれる列名をリンクと考えることができます：
*ファーストネーム
*姓
*メールアドレス（ランダムに人の名前から生成されます）
*住所の詳細（通り、住宅番号、郵便番号、場所、国）
*もっと多く

次に、ユーザーが作成したい行の数を設定することができます。アプリケーションは、ランダムに国を選択し、彼らが住んでいる国に応じて現実的な見た目のデータを生成します。

Answer 1

それは実際には素晴らしい質問です。このようなことは、データベース設計における真の問題につながり、真のトレードオフがあります。私はあなたが使用しているRDBMSのか分からないけど....

は、基本的には4つの選択肢、重大な欠点を持つそれらのすべてがあります。一つだけFKEYができ、チェック制約と
1.つMMテーブルを潜在的なテーブルごとに言語と1つの列のほかに入力します。 Ick ....
リレーションごとに1つのM-Mテーブル。これにより、ある時点で何かをintからbigintに変更する必要がある場合に、時間の経過とともに管理が非常に難しくなります。
多型関係を有する1つのM-Mテーブル。あなたがこれを行うときに参照整合性のチェックをたくさん失って、それを安全にして、楽しいコーディング（そしてテスト！）トリガーを持ってください。
4. rdbmsの高度な機能を慎重に検討してください。たとえば、postgresqlでは、これはテーブル継承で解決できます。欠点は、移植性を失い、高度な領域で終わることです。

残念ながら、一義的な回答はありません。トレードオフを慎重に検討し、あなたのプロジェクトにどんな意味があるかを決める必要があります。 1つのRDBMSだけで作業していた場合は、最後の作業を行います。しかし、そうでない場合は、関係ごとに1つのテーブルを作成し、発生する問題を管理するためのツールに焦点を当てるでしょう。しかし、以前の好みは私の知識と自信のレベルであり、後者はもう少し個人的な意見です。

これは、トレードオフを見て、あなたのために適切なものを選択するのに役立ちます。