0

私はあなたがあらゆる種類のアイテムを扱うプロジェクトに取り組んでいます。それが何であるかは重要ではありません。私が心配しているのはデータベースの設計です。このためにデータベースのレイアウトを作成する方法について誰かが私に洞察を与えることができれば、または正しい方向に私を向けることができれば、私は最も感謝しています.

あらゆる種類のアイテムを 1 つのリスト
に アイテムのリストがあるとします。CD のリスト、DVD のリスト、書籍のリストを作成できます。これは、1 つのリストにデータベース用語で多くの項目があり、項目行にリストの ID があることを意味します。
しかし、サウンドトラック DVD、恐ろしい実写映画、配管工の生活に基づいたファンフィクション小説など、スーパー マリオ関連のすべてのリストを作成したい場合はどうでしょうか。
データベースを作成しているときに、同じリストに属するアイテムを同じテーブルに入れることはできないことに突然気付きました。アーティスト/アルバムのタイトル、監督/映画のタイトル、作者/をサポートする列がすべて異なるためです。小説のタイトルなど.. 1つの巨大なテーブルにすべてを収めることはできませんでした.
さらに、サウンドトラック アルバムのトラック タイトルと映画の俳優をデータベースに登録したいと考えています。CD しかない場合は、album_track-table を item-table に簡単にアタッチできますが、すべての種類の異なるテーブルを item-table にアタッチすることはできません。特定のリストのすべての詳細を含むすべてのアイテムを取得したいと考えていました。リストに書籍、ビニール、マンガ、テレビシリーズ、植物、家具などが含まれていない場合でも、この手順では、添付されたすべてのテーブルでリストの参照を検索する必要があります。</p>

私が今持っているのは次のレイアウトです（しかし、これがこれを行うための最良の方法だとは想像できません）：

t_list (id) --> t_item (id, id_list, image)

t_item --> t_cd (id, id_item, artist, title)
t_item --> t_dvd (id, id_item, director, title)
t_item --> …

t_cd --> t_cd_track (id, id_cd, track_title, length)
t_dvd --> t_dvd_actors (id, id_dvd, actor_name, image)
…

カスタム列
ここで、これらのアイテムを cd リストに追加するために、テーブル t_cd の列 (アーティスト、アルバム タイトル、ジャンルなど) に従って、入力フィールドを持つフォームがあると想像してください。アルバムの平均価格などのカスタム入力フィールドを追加できるようにしたいと考えています。
これは、特定のリストの特定のユーザーに対して設定されます。これはアイテム レベルでは設定されません。これは、全員のフォームに追加されることを意味するためです。そのフィールドを自分の CD リストに追加したいだけです。
ただし、その値をデータベースに入力する必要があるため、アイテムに関連付ける必要があります。

私は次のようなことを考えています：

t_list (id) --> t_extra_field (id, description, id_list)
t_extra_field --> t_field_value (id, id_extra_field, value)

しかし、データベーススキームのどこにこれを添付するかは完全にはわかりません。

この種の構造は、私の以前の質問に対する答えでもありますか? ( t_field --> t_field_value) もしそうなら、私もそれをどこに付けたらよいかわかりません。上記の例で提案したように、おそらくリストする必要がありますか？
これは、特定のアイテムのすべての詳細が 1 つのテーブルにあることを意味しますが、アイテムに関連付けられた別のテーブルからの何らかのカテゴリ ID に従って、1 つのレコードではなく値ごとに格納されます。それは多くのレコードを含むテーブルになるため、ここでも私の疑問が生じます: これはパフォーマンスに悪いのではないでしょうか..?

誰かが私にこの問題についての洞察を与えてくれることを心から願っています..

4

1 に答える 1

4

完全に汎用的なデータベースは、おそらく悪い考えです。それは通常、アプリケーション レベルで完全にデータの一貫性を確保する必要があることを意味します。これは、実行時に DDL を回避したい場合に、高度に「型指定されていない」または「揮発性」のデータに対して正当化される可能性がありますが、ここで説明するデータは、より従来のデータベース設計には十分に「型指定された」ように見えます。

あなたの説明から判断すると、次のようなものが必要になります。

ここに画像の説明を入力

シンボルは「ここに画像の説明を入力カテゴリ」（別名、継承、サブタイプ、一般化階層など）を示します。

アイテムがどのように接続されるべきかが正確にわかっている特定のケースでは、TRACK テーブルの場合のように、特定のサブタイプ間のリンク (ジャンクション) テーブルを介して直接モデル化できます。

また、GROUP と GROUP_ITEM を使用してさまざまな種類のアイテムをグループ化できます (たとえば、マリオのサウンドトラック、映画、本を同じ GROUP_ID でグループ化できます)。

アーティストもかなり一般的な方法で扱われるため、たとえば、同じ人が曲と本の両方を書いている状況を簡単に表すことができます。

「アルバムの平均価格」などについては、理想的にはまったく保存しないでください。必要に応じて、既存のデータに基づいて計算することで、古い結果が得られる可能性が排除されます。

これがパフォーマンス面で問題になる場合は、次のいずれかを行います。

  • 定期的に実行し、結果をキャッシュして、やや古い結果を維持します。

  • または、(トリガーを介して) データが変更されるたびに結果をキャッシュしますが、並行環境での異常を避けるために非常に慎重に行います。

    例えば...

    SELECT AVG(PRICE) FROM TABLE1;
INSERT TABLE2 (AVERAGE_PRICE) VALUES (result_of_the_previous_query);

    ...ほぼ確実に安全ではありませんが、DBMS によっては...

    INSERT TABLE2 (AVERAGE_PRICE) VALUES (SELECT AVG(PRICE) FROM TABLE1);

    ...適切なロックがなければ、完全に安全ではない可能性があります。DBMS のトランザクションの分離とロックについて学ぶ必要があります。

    平均を計算する特定のケースでは、個別に COUNT を増分/減分し、各 INSERT/UPDATE/DELETE のトリガーを介して価格の SUM を加算/減算し、次に AVG を計算するなど、考慮できる他のトリックがあります。はえ。SQL は、 などUPDATE MY_COUNT = MY_COUNT + 1が「アトミック」であることを保証します。

于 2012-06-26T11:45:27.700 に答える