0

ZZ-bb に応えて、明確にしようと思いますが、ZZ は質問にかなり答えたと思います (ZZ-bb に感謝します)...

データベースでクリップボードの内容を表現したい。ユーザーがアイテムをクリップボードに追加し、後で戻ってきてもクリップボードにアクセスできるという考えです。

ユーザーは、画像、ファイル、テキストのチャンクなどをクリップボードに保存できます。

これは私が思ったことです

  • 1 ユーザー対 1 クリップボード
  • 1 クリップボードから多数へcb_items

ここにこすりがあります。cb_item文字、テキスト、画像の URL、ファイルの場所、おそらくグロブなど、何でも説明したいと思います。

この段階cb_itemで、エントリが必要とする可能性のあるすべての列を含むテーブル行を記述するか、何らかの方法で「ポリモーフィック」FK を作成することができます...

これを行うために私は考えました。

  • 1cb_item対1type
  • 1cb_item対1typed_cb_item

次に、型を使用して、検索するテーブルを決定しますtyped_cb_item。

例えば

  • cb_item #1 => { IMAGE_TYPE, 1 }
  • cb_item #2 => { FILE_GLOB, 1 }

テーブルを調べて情報をitem #1得るtyped_cb_item idからです。テーブルを調べて情報を得るからです。cb_image_itemitem #2typed_cb_item idcb_fileglob_item

編集- テーブルは次のようになります....

cb_item_tbl
-----------
   item_id (PK)
   user_id (FK referenceing user)
   type_id
   typed_item_id >------------+ - - like "typed_cb_item" above 
                              |
cb_image_item_tbl             |
-----------------             |
   img_item_id (PK) <---------+  }
   url (string)               |  }
                              |  } OR based on type_id
cb_file_item_tbl              |  }
----------------              |  }
   file_item_id (PK) <--------+  }
   file_name       
   file_size etc etc
   maybe a glob

これは、ソフトウェアに関する限り正常に機能しtyped_item_idますが、DB の実際の外部キーにすることはできないため、DB の参照整合性を使用できません。それを壊すべきではありません!)そしてクエリをより複雑にします。

誰か提案はありますか？この「ポリモーフィック」な FK のアイデアはおそらく最善の方法ではないと思いますが、その項目に関連する列のみを持つ項目テーブルに対処するために使用できるという事実が気に入っています。

コメントや提案があれば事前に乾杯...

4

1 に答える 1