1

これは問題の単純化されたバージョンです。

大量のデータを送信してクエリを実行する顧客がいます。彼らは、データを照会できるいくつかの「パブリック」ID を持っている必要があります。(ほとんどの場合、データと一緒に送信する ID を介してシステムにクエリを実行したいと考えていますが、常にそうとは限りません)。簡単にするために、それらを「pid」、「crid」、「musicbrainzid」と呼びます。この情報を格納する「エンティティ」テーブルがあります。次のようになります (「権限」はデータの送信者です)。

entity 
-- 
entity_id   
authority  // who sent the data
type       // 'pid', 'crid', 'musicbrainz', etc.
value      // the actual id value

次に、「エピソード」、「シリーズ」、「ブロードキャスト」などの個別のエンティティがあります (実際にはもっとたくさんありますが、ここでは単純にしています)。これらにはそれぞれ、エンティティ テーブルを指す entity_id があります。

外部の顧客は、どのように pid または crid を介して検索し、適切なエピソードまたはシリーズを取得し、それが何であるかを適切に識別することができますか? pid を指定すると、エンティティ ID を取得できますが、この値を求めてエピソード、シリーズ、ブロードキャスト テーブルを検索する必要があります。さらに、すべての ID が必ずしも他のすべてのテーブルに関連しているわけではありませんが、エンティティ (「エピソード」など) には複数の ID (pid、crid など) がある場合があります。

戦略:

  1. pid のエンティティ ID を見つけ、他のすべてのテーブルで pid を検索します。
  2. エンティティに「entity_type」列を配置しますが、それがエピソード テーブルの pid であるのに、誤って episode.type をシリーズとして設定した場合はどうなるでしょうか? データを複製したくないし、データベースのメタデータを列の値に入れたくありません。

オプション番号1は遅く、間違っているようです（さらに、さまざまなテーブルの構造が異なるため、問題が発生します）。

オプション 2 はデータが重複していることを意味し、このデータは同期しなくなる可能性があります。トリガーを使用してこれを強制することはできますが、これは非常にやっかいなことのように思えます。いずれにせよ、mysql トリガーの実装のバグに何度か遭遇しました。現在この戦略を使用していますが、トリガーはありません。

オプション 3 とは何ですか?

補足: すべての権限/タイプの組み合わせが有効であるとは限らないため、「権限」を別の表に分割する必要があることはわかっています。

4

1 に答える 1

3

あなたの質問を正しく理解していれば、オプション 1 を使用します。

entity_id に基づいて行を識別するクエリは、すべてのデータがインデックスにある必要があるため、それほど遅くはありません。
インデックスが正しく構成されていれば、実際のデータにアクセスすることさえありません。(少なくとも SQL Server ではそうではありません。)

私が行う小さな変更の 1 つは、テーブルの小さなセットを作成して、どの ID がどのテーブルに対して有効であるかを識別することです。
次に、これを使用して、検索する必要があるテーブルを絞り込みます。

オプション 1 または 2 の代わりに、データベース構造を完全に変更し、entity_id を主キーとして使用して同じテーブルに異なるデータを格納し、データを含む汎用列を使用することもできます。
これは確かにもっと急進的ですが、データとその構造が非常に動的であるあなたのようなシステムではうまく機能することがわかりました。

于 2008-10-21T12:49:12.917 に答える