2016-10-21 5 views
0

私はデータベース設計の初心者で、Groupon.comのようなgrouponウェブサイトのデータベース設計に問題があります。これは私の考えからの私のダイアグラムです。私はいくつかの助言を期待していますこのデータベースをより良くするにはどうすればよいですか?

  1. このEER図を改善するにはどうすればよいですか?

  2. 私が避けるべき一般的な間違いはありますか?

  3. 正しい軌道に乗っていますか?あるいは、私がまだ考慮していない代替デザインパターンを提案できますか?

詳細情報が必要な場合はお知らせください。

私の貧しい人々のために申し訳ありません。前もって感謝します!データベーススキーマについては

contextdiagramEER diagram

+0

を参照してください:[ファイブシンプルなデータベース設計エラーあなたは避けなければならない](https://www.simple-talk.com/sql/database-administration/five-simple--database-design -errors-you-should-avoid /) –

+0

クエリーが遅い場合、実際のアプリケーションのテーブルがどれほど美しく正規化されているかは関係ありません。したがって、設計する前にデータベースで何をしたいかを分析する方がよいでしょう。 dbを正規化し、その中のデータを少なくすることは、dbをRAMに収めて良好なパフォーマンスを提供するのに役立ちます。しかし、同じ周波数で照会されたデータのすべての部分が正規化を避ける方がよい場合があるためです。誰もあなたのデータの統計情報を知らせない限り、ドキュメントを読んで、あなたのデザインを試して、あなたの経験を得ることができます。 – yvs

答えて

0

、私が希望:

  1. 変更も、順序がオーダーステータスにFKを持つように。この方法では、 データベースのorderStatusレコードの数を最小限に抑えます。このようにして、ステータス(「進行中」、「新規」など)はほとんどなく、ご注文はそれに関連します。ちょうどあなたが支払いをしたのと同じです。注文合計はどこですか?
  2. 私はもっとアトミックなアドレスにします。それを国、都市、通り、郵便番号に分割します。そのように出荷を処理する方が簡単になります。
  3. purchaseItemテーブルを作成するのではなく、productOrderを作成し、製品にFK、注文するFK、アイテム数を持つ(多対多リレーションシップ)を作成します。このようにして、注文にはさまざまなアイテムが含まれます(productNameはそこに集約する必要はありません)。
  4. あなたはプロモーションでかなりいい仕事をしましたが、私の意見では、プログラム側からかなり大きな助けが必要になるでしょう。商品合計と注文合計を手動で計算する必要があります。

少し助けてください。助けが必要な場合は、コメントにお尋ねください。あなたのための
いくつかの読書:Database normalization

関連する問題