sql - Nデータベーステーブルを1つのマスターテーブルに結合するにはどうすればよいですか？

Question

N個の書店にN個のテーブルがあるとしましょう。各テーブルには異なるスキーム（列の数とタイプが異なる）があるため、本に関するデータを書店ごとに別々のテーブルに保持する必要がありますが、すべての書店テーブルに共通する同じ列のセットがあります。

次に、列が少ない1つの「MasterTable」を作成します。

|   MasterTable   |
|id. | title| isbn|     
| 1  | abc  | 123 |


| MasterToBookstores |
|m_id | tb_id | p_id |
| 1   |   1   |  2   |
| 1   |   2   |  1   |


|       BookStore_Foo          |
|p_id| title| isbn| date | size|     
| 1  | xyz  | 456 | 1998 | 3KB |
| 2  | abc  | 123 | 2003 | 4KB |

|       BookStore_Bar                  |
|p_id| title| isbn| publisher | Format |     
| 1  | abc  | 123 |   H&K     |   PDF  |
| 2  | mnh  | 986 |   Amazon  |   MOBI |

私の質問ですが、そのような方法でデータを保持するのは正しいですか？これと同様のケースについてのベストプラクティスは何ですか？特定の書店のテーブルに番号付きのエイリアスを付けることはできますか？これは、テーブルのセット全体を管理するのに役立ちますか？

そのようなことをするより良い方法はありますか？

Answer 1

I think you are confusing the concepts of "store" and "book".

From you comments and the example data, it appears the problem is in having different sets of attributes for books, not stores. If so, you'll need a structure similar to this:

The symbol: denotes inheritance¹. The BOOK is the "base class" and BOOK1/BOOK2/BOOK3 are various "subclasses"². This is a common strategy when entities share a set of attributes or relationships³. For the fuller explanation of this concept, please search for "Subtype Relationships" in the ERwin Methods Guide.

Unfortunately, inheritance is not directly supported by current relational databases, so you'll need to transform this hierarchy into plain tables. There are generally 3 strategies for doing so, as described in these posts:

• Interpreting ER diagram
• Parent and Child tables - ensuring children are complete
• Supertype-subtype database design

NOTE: The structure above allows various book types to be mixed inside the same bookstore. Let me know if that's not desirable (i.e. you need exactly one type of books in any given bookstore)...

---

¹ Aka. category, subclassing, subtyping, generalization hierarchy etc.

² I.e. types of books, depending on which attributes they require.

³ In this case, books of all types are in the many-to-many relationship with stores.

Answer 2

他のすべてのテーブルが使用する列が少なくとも 2 つある場合は、すべての書籍のベース テーブルを作成し、ベース テーブルの ID を使用して残りのデータのテーブルを追加できます。

アップデート：

エンティティ フレームワークを使用して DB に接続する場合は、これを試すことをお勧めします。

次のようなエンティティ モデルを作成します。

次に、エンティティ フレームワークにデータベースを生成させます (モデルからデータベースを更新)。これは継承を使用することに注意してください（データベースではありません）。

ご不明な点がございましたら、お知らせください。

Answer 3

次の 2 つのテーブルを用意することをお勧めします。

書店:

id name someMoreColumns

本:

id bookStore_id title isbn date publisher format size someMoreColumns

ここで関係を確認するのは簡単です: a bookStorehas many books.

BookStore一部のテーブルの一部の行に一部の列の値がない場合でも、すべてのテーブルにあるすべての列を 1 つのテーブルに配置していることに注意してください。

私がこの方法を好む理由：

1) テーブルのすべてのデータに対して、テーブルに値が含まれないBookStore列はごくわずかです(例として、電子書籍版がない場合)。他の列はいつか埋めることができます (電子書籍に a を設定できますが、電子書籍を参照しているように見えるこの列が表にありません)。このようにして、いつか更新したい場合に、すべての本からより詳細な情報を得ることができます。bookssizeformatdateBookStore_Bar

2) テーブルがたくさんある場合BookStore、たとえば 12 の場合、データを簡単に処理することはできません。私が言いたいのは、すべての本 (つまりすべてのテーブル) に対して何らかのクエリを実行したい場合、少なくとも 3 つの方法があるということです。

• まず、12 個のテーブルのそれぞれに対して手動でクエリを実行し、データをマージします。

• 2 番目:FROM句に12 個の結合を含むクエリを作成するか、12 個のテーブルを設定して、すべてのデータをクエリします。

• 3 番目: スクリプト、ストアド プロシージャ、またはソフトウェアに依存して、先ほど述べた最初または 2 番目の方法を実行します。

本当に必要でない限り、他のスクリプトやソフトウェアに依存せずに、できるだけ簡単にデータを処理できるようにしたいと考えています。

3）MySQLの時点で（私はMySQLについてもっと知っているため）partitions、テーブルで使用できますbooks。これは高レベルのデータ管理であり、通常はテーブルが割り当てられるため、テーブルのデータをディスク上の 1 つだけではなく複数のファイルに分散できます。同じテーブルで大量のデータを処理する場合に非常に便利で、データ分散計画に基づいてクエリを高速化します。例を見てみましょう：

既に 12 の個別の本屋があるとしますが、私のデータベース モデルではそうです。テーブルの行ごとbooksに、12 の bookStore の 1 つに関連付けられます。データを でパーティション分割するbookStore_idと、12 個のテーブルがあった場合とほぼ同じになります。これは、それぞれに対してパーティションを作成できるため、bookStore_id各パーティションは関連データ ( に一致するデータ) のみを処理するためbookStore_idです。

(1, 4, 9)のテーブルbooksにクエリを実行するとします。bookStore_id必要な出力を得るためにクエリで本当にこれら 3 つのパーティションが必要な場合、他のパーティションはクエリされず、分離された各テーブルをクエリするのと同じくらい高速になります。

パーティションを削除しても、他のパーティションは影響を受けません。新しいパーティションを追加して、新しいブックストアを処理できます。パーティションをサブパーティション化できます。2 つのパーティションをマージできます。簡単に言えば、シングルテーブルbooksを扱いやすいマルチ収納テーブルに変えることができます。

副作用：

1) 私はテーブルの分割をすべて知っているわけではないので、ドキュメントを参照して、それを作成および管理するためのすべての重要なポイントを学ぶことをお勧めします。

2) テーブルのデータが非常に多い可能性があるため、定期的なバックアップ (ダンプ) でデータを管理してくださいbooks。

お役に立てば幸いです。

Answer 4

提案するデータ モデル:
1. マスター データを保存
するマスター データベースを用意する 2. マスター データベースのディメンション テーブルを、分散書店データベースに一時的に複製する
3. 更新可能なスクライバーを使用するか、マージ レプリケーションを使用するかを選択することもできます
4.各分散書店データベースは引き続き独立して動作しますが、マスター データはマージ レプリケーションまたは更新可能なサブスクライバーによってマージ バックされます。
5.マスターデータの整合性を確保したい場合は、読み取り専用のサブスクライバーのみを使用し、トランザクションレプリケーションを使用してマスターデータを分散データベースに配布できますが、この設計では、マスターデータベースにストアプロシージャを用意してディメンションを登録する必要がありますデータ。ダブルホップの問題がないことを確認してください。