2017-05-19 5 views
0

私は、書籍/テーブルコンセプトと一緒にオンライン食糧配達システムを開発しようと考えています。市場にはただ1人の競合相手しかいません。それで、私はユーザーフレンドリーな完全なフィーチャーパッケージを考え出したいのです。私はデータベースを設計しましたが、データベース設計をどのように拡張または簡素化できるか、専門家の考えを引き継いでいきたいと思います。最適なデータベース設計のアイデアをお寄せください。私はより良いデザインと私のデータベースを構築する必要がありますどのようにオンライン食糧配達システムのためのデータベースデザインブック付きテーブル

Customer 
    user(FK) 
    first_name 
    last_name 
    phone_number 
    email 
    address 
    liked_restaurant(M2M) 

Restaurant 
    user(FK) 
    name 
    city 
    place 
    phone_number 
    email 
    website 
    banner 
    view 
    lat 
    lang 
    speciality 
    opening_time 
    closing_time 
    features(M2M) # like Breakfast, Lunch, Night Life etc 
    status(open or closed) 
    is_parking 
    is_wifi 
    timings(M2M) # sunday opening&closing time, monday opening&closing time, ... etc 

Category 
    menu_category 

Menu 
    restaurant(FK) 
    category(FK) 
    name 
    price 
    minimum_quantity 
    available 
    rating 

Order 
    user(FK) 
    order_id(PK) 
    food_id(M2M) 
    restaurant_id(FK) 
    quantity 
    total_price 


BookTable 
    user(FK) 
    restaurant(FK) 
    quantity 
    type - table/cabin/hall 

Review 

:ここ

は、私が出ている何ですか?私が間違ってやったことはありますか?

+0

これは意見に基づく質問ですが、私は2セントを払うつもりです。うまく見えますが、エンティティ "Order"を修正する必要があります。プロパティ "order_id(PK)"は不必要です。 Djangoはあなたが本当に自分で設定したいのでなければ、プライマリキーを自動的に設定します。どのプロパティがエンティティ "レビュー"を持っていますか?ここでいくつかのプロパティが必要です。 – cezar

+0

私はレビューについて考えていません。 order_idに関しては間違いでした。私は乱数生成を使って注文番号を持っていました。 – pythonBeginner

+0

これはCodeReviewに適しています。 – Matt

答えて

1

私のコメントで述べたように、これは意見に基づく質問であり、多くの異なる回答があります。また、この質問は実際にstackoverflowのようなサイトには適していません。

しかし、お手伝いしましょう。

Customer 
    user(FK) # why do you need this? 

あなたはジャンゴUserクラスを拡張したい場合は、これは本当に仕事をしないだろう。お客様とユーザーの間には1対1の関係が必要です。他のモデルでも、Customerを参照し、Userには参照しないでください。 だから、むしろそれを作る:エンティティRestaurant(および他のすべてのエンティティ)で

Customer(models.Model): 
    user = models.OneToOneField('User', ...) 

Customerへの参照。私はなぜあなたがユーザー:レストラン1:nの関係を持っているのだろうかと思っています。とにかくそれを次のように変更する必要があります:

もし可能であれば、PostgreSQLとオープン時間のJSONフィールドを使用してください。そして、あなたはこのような何かを持つことができます。

timings = JSONField() 

をし、JSONは次のようになります。

{ 
    'Monday' : { 
     'opens': '10am', 
     'closes': '10pm' 
    }, 
    'Tuesday' : { 
     'dayoff': true 
    }, 
    'Wednesday': { 
     'opens': '9am', 
     'closes': '11pm' 
    } 
    # and so on 
} 

あなたが(とすべきである)異なるフォーマットで時間を置くことができますが、これは単なる例示です。 JSONは非常に柔軟性があり、1日ごとに別のプロパティを持つことができます。休憩(レストランは午後9時から午後2時まで開いてから午後10時まで開いてから午後5時に休憩します)。そのため、プロパティーopening_time,closing_timeおよびtimingsを削除して、このJSONフィールドにマージする必要があります。

statusを仮想フィールドにします。現在の時刻を取得し、レストランが開いているか閉じているかを確認するメソッドを記述します。これをデータベースに保持しないでください。

エンティティMenuは、むしろMealまたはMenuItemと呼ばれる必要があります。あなたの変数の名前をどのように考えるか。命名は非常に重要です。私はプログラミングにおいて最も重要なことを言っています。クラス、メソッド、またはプロパティの名前を正しく指定できない場合は、それが何であるかは分かりません。

Orderには、food_id(M2M)restaurant(FK)があります。どうして? food_id(M2M)が前のモデルに行くと、そこにレストランがあります。 "ビーフバーガー"、 "チキンガンボ"などと言うようなものを持っていない限り、それは多くの異なるレストランで提供することができます。 quantityOrderのプロパティはなぜですか?注文を考えると、次のようになります。

- 3 beers 
- 1 coke 
- 2 buffallo wings 
- 1 spare ribs 
- 1 nachos 

この商品は売り切れです。

OrderFood(models.Model): 
    order_id(FK) 
    food_id(FK) 
    quantity 

私はもっと書くことができるが、それは今のところです:私はジャンゴであなたも、必要に応じて追加のフィールドで、throughテーブルを指定し、そのモデルを定義することができ、余分なフィールドを持つM2M表にしてください。私はそれが少しあなたを助けることを願っています。 紙の上にすべてを置いてください。あなたのエンティティを描く - 名前を書かない - スケッチを作る。顧客、レストラン、テーブル、食べ物を描き、それらに特性を割り当て、どの関係にあるかを考えます。

EDIT:

チェックJSONFieldのドキュメント: https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/fields/#jsonfield

私は標準のリレーショナルデータベースとしての骨格を作成し、JSON内のすべての柔軟な性質を置くところ。メニューによっては、レストランによって大きく異なると考えることができます。ファストフードは、離れて取ることができます:

{ 
    'Burgers': [ 
     'Hamburger', 
     'Cheesburger' 
    ], 
    'Beverages': [ 
     'Coke', 
     'Fanta' 
    ] 
} 

と高貴なフレンチレストランでは持つことができます。

{ 
    'Entrees': [ 
     ... whatever 
    ], 
    'Main courses': [ 
     {'Poultry': [ ... ]}, 
     {'Beef': [ ... ]}, 
     {'Fish': [ ... ]} 
    ], 
    'Deserts': [ 
     ... whatever 
    ], 
    'Beverages': [ 
     {'Wines': [ 
      {'White': [...]}, 
      {'Red': [...]} 
     }, 
     {'Aperitifs': [...]}, 
     {'Beers': [...]} 
    ] 
} 

EDIT:仮想モデルのフィールドに

を説明する仮想モデルフィールドをモデルエンティティはプロパティを持つ意味これはデータベースに永続化されず、データベース表の列として存在しません。

例:statusについて

import calendar 
from datetime import datetime 

Restaurant(models.Model): 
    timings = JSONField() 

    # illustrational code, not for production 
    def _get_status(self): 
     now = datetime.now() 
     weekday = calendar.day_name[now.weekday()] 
     if self.timings.get(weekday, False): 
      open = self.timings[weekday].get('opens', 0) 
      close = self.timings[weekday].get('closes', 0) 
      if now.hour() >= open && now.hour() < close: 
       status = 'open' 
      else: 
       status = 'closed' 
     else: 
      status = 'closed' 
     return status 

    status = property(_get_status) 
    status.short_description('Status open-closed') 

表の列が存在しないであろう。現在の瞬間に依存するので、データベースにその値を保存しません。したがって、レストランが現在開いているかどうかを確認します。現在の曜日と現在の時間を取得し、JSONFieldの値と比較することができます。

+0

詳細な説明をありがとう。私はあなたの親切さに感謝します。バーチャル化しているステータスについては、わかりませんでした。 – pythonBeginner

+0

最後の1つの質問は、食事はveg、no-veg、sweetsなどのカテゴリを持つことができ、イタリア、インド、フランスなどの料理もあるので混乱しているので、jsonfieldが最高になりますそのような状況のためにjsonfieldを説明したり、別のテーブルを作ったりしているようです。私はより良いカテゴリーのための食事のデザインと混乱しているので、より良いフィルタリングシステムを構築することができます。 – pythonBeginner

+0

はい、混乱します。そしてそれは食事だけでなく、飲み物でもあります。私は "メニュー"をエンティティとして考えています。それ自体が "レストラン"のプロパティです。 「メニュー」には食べ物や飲み物などのアイテムがあります。ですから、食事と飲み物の両方にまたがる名前を考えなければいけません。私はそれを「MenuItem」と呼んでいます。 「MenuItem」は中国料理やインド料理の食べ物ですが、ワイン、フランス料理、イタリアンなどがあります。これは非常に柔軟性があるかスキーマであることがわかります。したがって、PostgreSQLをJSONで使用することをお勧めします。これは、リレーショナルDBとドキュメント指向DBの両方を最大限に活用します。 – cezar

関連する問題