-1

私はこの構造の多くのオブジェクトを持っています:

~ PlaceID
  = Upvotes
  = Downvotes
  = Names
    - Title 
      + Upvotes
      + Downvotes
    - Other names[]
      + Upvotes 
      + Downvotes
  = Location
    - Lat
    - Long
    - Address
  = Images
    - Top 
      + id/url
      + Upvotes
      + Downvotes
    - Others[]
      + Upvotes
      + Downvotes
  = Comments[]
    - id
    - Text
    - Upvotes
    - Downvotes
    - ReplyTo

整理しておくために、多くのリンクを含むスキーマをレイアウトしました。これはテーブルの例です:

7741 (プレイスID)

______________________________________________________________________________
names      | location      | upvotes | downvotes | images      | Comments
_______________________________________________________________________________
7741_names | 7741_location |    20   |     3     | 7741_images |  7741_comments

次に、たとえば 7741_images (スコアでソートされているため、「トップ」アイテムが簡単に取得できます):

 imgID   | score | upvotes | downvotes | url              |
________________________________________________________
 7741_21 | 98    |    44   |     1     | /img/7741_21.png |
 7741_14 | 94    |    40   |     2     | /img/7741_14.png |

オブジェクトごとに多数のテーブルを使用するこのドリルダウン スタイルでは、クエリが非常に遅くなったり、非常に具体的なクエリが過度に冗長になったりしますか? (100k の場所の場合?)

私はスキーマの設計を担当したことがないので、明らかなことを見逃していたらすみません。

4

1 に答える 1

1

それが悪いか良いかは主観的な品質です-あなたが提起した質問（およびスキーマ）に基づいています。その質問に適切に答えるには、スキーマ設計の決定を説明することが不可欠です。決定には常に正当な理由が必要であり、開発中にそれが正しくないことが判明した場合は、改善を繰り返す必要があります。:)

アプリをサポートするためにスキーマを設計するための事前の試みを行っていると仮定すると、ニールが指摘したアプローチから始めます。サンプル スキーマでは、特定の状況下でパフォーマンスが問題になります。

繰り返しますが、単純なことから始めて、修正する必要がある場合は、デザインの選択に正当な理由があることに「満足」していることを確認してください.

于 2013-09-16T19:30:41.707 に答える