7

SQL Server バックエンドを備えた asp.net-mvc Web サイトがあります。問題を強調して切り分けるために、状況を単純化しています。DBに3つのテーブルがあります

  1. 記事テーブル (id、名前、コンテンツ)
  2. ロケーション テーブル (id、名前)
  3. ArticleLocation テーブル (id、記事 ID、場所 ID)

私の Web サイトでは、記事を作成するときに、その記事を送信したい場所を複数選択リストボックスから選択します。

約 25 の場所があるので、リストボックスから 25 の異なるアイテムを選択させる代わりに、「グローバル」という新しい場所をショートカットとして追加することについて議論していました。フロントエンドのショートカットとしてこれを実行することもできますが、これをバックエンドに流すメリットがあるかどうかについては現在議論中です。

したがって、ArticleLocation テーブルに 25 のレコードを保持する代わりに、グローバル化する記事がある場合、1 つだけを保持し、フロント エンドでいくつかのトリックを実行してすべての項目を選択します。これが非常に悪い考えであるかどうかを理解しようとしています。

私が考えることができることは私を緊張させます:

  1. 記事を作成してグローバルを選択するとどうなりますか?その後、最後に 3 つの新しい場所が追加されます。このグローバル設定がなければ、これら 3 つの場所は記事を取得できませんが、新しい方法では取得します。2番目のものが実際にあなたが望むものかもしれないので、何が良いのかわかりませんが、少し明確ではありません.

  2. レポートに関する要件があり、グローバルなすべての記事でフィルター処理したいと考えています。article.IsGlobal() メソッドが必要になると想像してください。現時点では、プロジェクトにロケーション テーブル内のすべてのレコードと同じ数のロケーションがある場合、それをグローバルと見なすことができると言えますが、人々が新しいロケーションを追加できるため、このアプローチはやや不安定なように感じます。 .

「すべてのレコード」を実際に反映する参照データテーブルにレコードを作成することに関するこのジレンマについて、誰か提案はありますか? アドバイスをいただければ幸いです

4

6 に答える 6

2

tl;dr

この場合、私が理解しているように、Location テーブルに「グローバル」な場所を作成することをお勧めします。Articleテーブルに「グローバル」フラグを作成するよりも、間違いなく好ましいと思います。


「それは良い考えですか...?」SOで答えたい質問ではありません。これは主にディベートの質問であり、Q&A の質問ではありません。さらに、私たちのコミュニティには十分な創造性があり、いずれにせよ「それ」が良いアイデアである例を考え出すことができます。

より具体的な質問に対して、データベース内の「すべての場所」をどのように表すのですか? これは、ビジネス要件に基づいた判断です。

「すべての場所」に将来の場所を含めますか?

そうでない場合は、データベース内の現在のすべての場所を選択するヘルパーとして「すべての場所」のみを実装する必要があります。

場所の階層があると予想していますか?

現実世界の場所には重要な階層があります。

  • グローバル
  • 多国籍 (大陸、取引ブロック)
  • 行政区域 (州、州、カントンなど)
  • 近所

たとえば、グローバルではなく国を選択するオプションが必要な場合は、Damir が提案するような階層表現を実装するのが最善の方法です。ただし、グローバル以外に場所をグループ化する予定があるかどうかわからない場合は、現時点では階層的なデータ構造を使用するのは面倒です。必要なのは、現在の実装に将来の階層表現への移行パスがあることを確認することだけです。

疑似ロケーションとしてのグローバル

将来の場所をグローバルに含めたいが、階層的な場所構造は必要ない場合、長年の経験に基づく私の本能は、疑似場所として「グローバル」を作成することです。つまり、Global は Location テーブルのロケーションの 1 つですが、特別な意味があります。これは間違いなくトレードオフですが、グローバルをサポートするためにデータ構造を変更しないという利点があります。つまり、「グローバル」が作成するすべての特別なケースは、どこかでいくつかのフラグをチェックするのではなく、クエリでいくつかのロケーションを除外または含めることによって処理されます。 . (または、フラグが好きな場合は、「疑似ロケーション」フラグを Location テーブルに追加できます。)

Global を場所として使用すると、Location テーブルへの追加または削除が自動的に処理されます。すべてのグローバル記事のクエリは簡単です。他の場所のすべての記事のクエリと同じです。場所ごとの記事のレポートも簡単で、他の場所と同じようにグローバル記事がレポートに表示されます。また、「グローバル」記事 (現在および将来のすべての場所) と「すべての場所」記事 (現在のすべての場所で将来の場所は含まない)の違いを表すこともできます。

特定の場所で表示する必要があるすべての記事を選択するのは少し難しく、現在は「グローバル」とその場所に対するチェックですが、少なくとも同じテーブルの 2 つの値をチェックするのではなく、2 つの異なるテーブルをチェックしています。

SELECT article_id FROM ArticleLocation WHERE location_id in (1, 5);

SELECT article_id FROM ArticleLocation WHERE location_id = 5
UNION
SELECT id FROM Article WHERE is_global;
于 2013-06-06T17:13:33.853 に答える
1

あなたが説明したように、ロジックから、GLOBALは実際にはグローバルであり、新しい場所を追加してもグローバルのままである必要があります(問題1は解決されました)。ただし、これは GLOBAL が「すべての場所」と同じではないことも意味します (まだ定義していない場所が他にも存在する可能性があるため)。このロジックは、特に要件 2 で必要だと思います。そうしないと、新しい場所の追加に完全に失敗します。

分析完了!上記から、GLOBAL はこれらすべての場所の上にあることがわかります。それを場所として定義しようとしても意味がありません。最も簡単な解決策を探しましょう!

  • 記事テーブル (id、name、content、global )

ブール値フラグ - 記事がグローバルかどうか。UI では、単純にチェックボックスとして実行します。チェックすると、複数選択ボックスが無効になります。シンプル、簡単、要件を満たしました。終わり!

于 2013-06-11T01:52:08.677 に答える
0

@HABOのコメントに同意します(彼は投稿するべきでした-投稿した場合は、彼に賛成票を投じてください)。テーブル Article に属性を追加して、おそらく記事の存続期間中、現在および将来のすべての場所に関連付けられるアイテムを特定すると、長期的には時間と労力を節約できます。確かに、トリガーとcounts-against-allはそのトリックを行いますが、それらは厄介であり、その後のシステム変更が発生した場合にサポートするのは面倒です. ユーザーはチェックボックス (またはその他のもの) をクリックするだけでよく、予測不可能な長さのドロップダウン内のすべてを複数クリックする必要がないため、UI はより簡単に使用できます。

(@Damir の階層のアイデアも同様に機能しますが、少し経験が多すぎると言えば、それらを使用するのは面倒であり、システムやビジネスでの使用が大幅に増えない限り、ここでは紹介しません。そこから抜け出すために。)

于 2013-06-06T15:25:09.497 に答える