Weasley-モデリング

主な項目

今回の最初のプロジェクトは、クローンワイドワークの「Weasley」です.英雄同盟公式サイトとOP.GGサイトを統合したサービスを作ろうとしたが、著作権問題やapiへの高度な依存などの問題でこのプロジェクトが行われた.その後、op.ggクローン符号化には独自のアイデアがあります(もちろんapiだけではなく、追加の機能を実現します…?)3名のバックグラウンドと3名のフロントからなる6名のチームで行います.

モデリング

バックグラウンドを担当して初日と翌日はほぼSQLDBMとモデルずっとPyと一緒にいます.

(小さくて貴重な私のモデリング...)
私はよくやったとは言えませんが、必要な情報をどのように管理すればいいかを感じています.

モデリングコメント

モデルが最初に完了すると、Ordersテーブルは1つに管理されます.

orders
|__id
|__order_number
|__user_id
|__product_id
|__amount
|__shipping_number
|__shipping_company
|__order_status
|__address_id

すべての商品は、同じ構造で管理され、一度に購入され、一度に管理され、一度に配送されると思っていました.Market Collieのようにある会社でパッケージや配送をすれば、必ず一緒に発送し、一緒に到着すると考えているからだ.
しかし、コメントの過程で、クボン(もちろん)、Market Colleyは商品別に配送できることが分かったので、注文状態/配送状態を管理するため、Order items表も作成しました.

orders
|__id
|__order_number
|__address_id
|__user_id
|__order_status_id

order_items
|__id
|__product_id
|__amount
|__shipping_company_id
|__order_item_status_id
|__order_id
|__shipping_number

に示すように、商品ごとに個別配送が可能な場合は、取り換え可能となり、注文/配送状態、宅配会社等の価格が正規化されておらず、重複していない価格は個別にテーブル管理されます.
このようにテーブルを分けて商品ごとに個別に配送する場合、ステータスやインボイス番号などが管理しやすくなり、注文番号も独自の管理が可能になります.
残りのテーブルはInstagramバックエンドクローンエンコーディングと似ているか、容易であるため、単独で整理されていない.さらにブログのトピックは、後で実装されるサブスクリプション機能(サブスクリプションコンテンツの登録/閲覧と次の支払い日の自動更新)かもしれません.

mysql bytes error

すべてのモデリングと移行を完了したとき、mysqlエラーに遭遇しました.バイトエラーは初めて見ました(スクリーンショットするべきですが、まだプログラマーではありません).
このエラーはすぐに解決でき、エラーは3072バイトを超えるテーブルの列を設定し、utf 8とは異なり、utf 8 mb 4は4バイトを知らず、1024文字以上の長さを電子メールフィールドに与えた.
メールフィールドを500文字に減らしました(ユーザーを信じて...!変なことをしないでください!)これが移行であり,エラーが解決された.何を置いてもいいという習慣を改めて、たくさんの空間を与えるべきだと思います(空間を割り当ててダイエットします).