0

私たちのチケット システムでは、チケットのさまざまな要件に応じて、チケットの種類ごとに異なる種類のフィールドを格納するためにさまざまなテーブル構造が必要です。例: 製品に対する顧客の苦情のチケットには、顧客番号が必要です。と商品IDですが、簡易お問い合わせのチケットは商品IDは不要です。チケットの種類によっては、お客様番号が不要な場合があります。また。

このシステムには、製品の詳細や顧客の詳細などの動的な詳細を含む分析およびレポート機能も必要です。

解決策として、動的な DB 構造をサポートし、分析およびレポート機能の効率を向上させる非 SQL DB (ここでは Cassandra) を考えました。しかし、これまで非 SQL DB を使用したことがないため、このソリューションについてはよくわかりません。

誰かがより良い解決策を提案したり、この問題に対する非 SQL ソリューションの考えに光を当てることはできますか?

4

2 に答える 2

1

私が推奨する設計は、オブジェクト指向言語で行う方法に似ています。これにより、潜在的に複雑な結合のオーバーヘッドと、複数のテーブルのオーバーヘッドが発生します。データベースを次のようにレイアウトします。 

Table GeneralTickets  
(  
    ticket_id number,  
    customer_id number,
    ... other fields that are **common to all tickets**
)    

Table ComplaintTickets
(  
    complaint_id number,
    ticket_id number (FK to GeneralTickets#ticket_id),  
    product_id number,
    ... other fields
)   

Table FeatureTickets  
(  
    feature_id number,
    ticket_id number (FK to GeneralTickets#ticket_id),  
    ... other fields
)

この場合、No-SQL ソリューションはあなたが探しているものではありません。この問題は 1) 関係データベースにより適切であり、2) No-SQL ソリューションに適切なほど多くのデータを記録しているとは思えません。

アップデート

レポート機能に関しては、私はまだこのリレーショナル データベースにこだわっています。基本的に、解決する必要があるデータ ウェアハウスの問題があります。やりたいことは、一連のベース テーブルを用意することです (これらは、最終的にレポートを作成するテーブルになります)。これらのベース テーブルから、 と呼ばれるものを作成しますmaterialized views。これらmaterialized viewsは、特定の期間 (つまり、1 月のレポート) について計算された後のすべてのデータを処理します。

あなたが言ったように、複雑な結合と複数のテーブルのオーバーヘッドは、私が No-SQL ソリューションを考えている主な要因です。SQL ソリューションはメンテナンスを増やし、パフォーマンスも低下させます。チケット システムは他のシステムと密接に結びついていないと思います。製品の詳細や顧客の詳細などの他の詳細については、変更イベントで SQL DB から同期することがあります。2番目の問題をどのように考えるか説明してもらえますか?

今、あなたが残したコメントに。SQL は、書き方が悪い場合にのみ遅くなります。これが、デカルト結合と単純なインデックス ルックアップの違いです。メンテナンスは、これらすべてにおいて小さな役割を果たします。ただし、ドメイン オブジェクト (結果セットの処理後に初期化されるクラス) を見ずにメンテナンスの側面について話すことはできません。ドメインを現在よりも正確になるように変更する必要がある可能性があります(間違っていると言っているのではなく、より正確になる可能性があるというだけです)。複数のシステムの同期を維持することは、最もやりたくないことの 1 つです。

于 2012-11-05T20:07:02.480 に答える
0

古風な言い方をしますが、通常のリレーショナル データベースをお勧めします。「さまざまな要件」が実際にそれほど変化していて、参照整合性や ACID プロパティではなく NoSQL ソリューションを保証するものであるとしたら、私は驚くでしょう。その理由の 1 つは、通常の RDBMS ではさまざまなレポート ソリューションが利用できることを知っているからです。

つまり、オプションの (つまり、null 可能な) フィールドを持つチケットをモデル化したり、チケットのいくつかのサブタイプを定義したり (つまり、継承を使用して - http://blogs.microsoft.co.il/blogs/bursteg/archive/2007を参照) することはできませんか? /09/30/how-to-model-inheritance-in-databases.aspx )。

于 2012-11-05T21:07:11.783 に答える