商品、訂單、購物車和訂單商品快照的關系，初步了解成為架構師的思想

hover_lew 發布于2019-08-16 15:45 / 4778人閱讀

摘要：訂單快照，比如我們昨天購買的商品材料，其當時的零售價是元，但今天就變成了元。此時我們在網頁上看到的材料價格是元，而我們付款的時候是元。商家是退給我們多少錢呢元，還是元當然，是元，而不是元。這元存儲在哪里呢就是訂單快照表。

導讀

最近見同事在做訂單和訂單材料快照這方面的業務，這其實就像淘寶上的商品，不過，這里是材料商品了。它一共涉及到 五張表 ：

材料表，材料的詳細信息

訂單表，用戶購買材料時的記錄表

購物車，待付款材料

用戶表，誰購買了材料

訂單材料快照表，這就是訂單和材料的快照

因而，這里面就涉及到一對一的關系。

一對一的關系

雖然一對一的關系用的不多，但我們有時也會設計這方面的數據表，不常用不代表不用。

分表一般會使用一對一的關系，比如說用戶表和用戶擴展表。用戶表存儲用戶必填的信息，比如賬號、性別、密碼、登錄時間、退出時間等。用戶擴展表就是用戶的擴展信息，比如愛好、昵稱等。用戶可填可不填的。數據如果都放在同一張表中運維人員會感覺比較亂。

如下，是部分的用戶實體和用戶擴展實體的代碼：

用戶表的部分數據

@Entity
@Table(name = "core_user")
public class User {
    
      /**
     * 用戶名，唯一
     */
    @NotEmpty(message = "用戶名不能為空")
    @Column(length = 100, unique = true, nullable = false)
    private String username;
    
    /**
     * 密碼
     */
    @Column(nullable = false, length = 66)
    private String password;
    
      /**
     * 用戶擴展表
     */
    @OneToOne(mappedBy = "user", fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    private UserExt userExt;
    
    。。。。
}

用戶擴展表的部分數據

@Entity
@Table(name = "core_user_ext")
public class UserExt implements Serializable {
 
    @OneToOne
    @PrimaryKeyJoinColumn
    private User user;

    /**
     * 自我介紹
     */
    @Lob
    @Basic(fetch = FetchType.LAZY)
    @Column(name = "introduce", columnDefinition = "text")
    private String introduce;

    /**
     * 性別
     */
    @Enumerated(EnumType.STRING)
    @Column(name = "gender", length = 20)
    private GenderEnum gender;


    /**
     * 昵稱
     */
    @Column(name = "nick_name", length = 66)
    private String nickName;


    /**
     * 真實姓名
     */
    @Column(name = "real_name", length = 100)
    private String realName;
    
    /**
     * 頭像
     */
    @ManyToOne
    @JoinColumn(name = "head_image")
    private Picture headImage;

    /**
     * 聯系地址
     */
    @Column(name = "address", length = 200)
    private String address;

    /**
     * 郵政編碼
     */
    @Column(name = "postal_code")
    private String postalCode;

    @Column(name = "qq", length = 66)
    private String qq;

    /**
     * 身高
     */
    @Column(length = 3)
    private Integer height;

    /**
     * 喜歡的運動
     */
    @Column(name = "loved_sports", length = 255)
    private String lovedSports;

    /**
     * 喜歡的電影
     */
    @Column(name = "loved_movies", length = 255)
    private String lovedMovies;

    /**
     * 喜歡的音樂
     */
    @Column(name = "loved_musics", length = 255)
    private String lovedMusics;

    /**
     * 喜歡的食物
     */
    @Column(name = "loved_foods", length = 255)
    private String lovedFoods;

    /**
     * 喜歡的書
     */
    @Column(name = "loved_books", length = 255)
    private String lovedBooks;

    /**
     * 喜歡的游戲
     */
    @Column(name = "loved_games", length = 255)
    private String lovedGames;
}

用戶擴展信息是用戶的輔助信息，它們適合一對一的關系。

詳解客戶材料（商品）、用戶材料（商品）、訂單、購物車、用戶、和訂單商品快照

用戶，是誰購買了這個商品，這是我們需要知道的。

材料商材料（材料商的商品），因為，我們這個平臺主要是售賣裝修材料的，其分為兩部分。一部分是材料商在平臺上掛出他們的材料，材料商下的經銷商購買材料。他們購買材料后，這就涉及另一部分，即經銷商掛出他們的材料。這時才賣給用戶，因而，對于經銷商來說，還要有一個市場零售價。

經銷商材料（經銷商的商品）：正如上面所說，我是經銷商，從材料商那邊購買了產品，然后，在我的這部分平臺上售賣，此時，用戶從我這邊購買了，然后將其加入到購物車中。

訂單，即為我們在購買裝修材料時所生成的一條購買記錄。

購物車，即為我們已經選好了商品，暫時還沒有進行付款，只是暫存起來，這也是一條記錄。等我們付款的時候，就從購物車中付款了。

訂單快照，比如我們昨天購買的商品材料，其當時的零售價是25元，但今天就變成了40元。我們拿到材料后，感覺不大合適，于是，申請退還材料。此時我們在網頁上看到的材料價格是40元，而我們付款的時候是25元。商家是退給我們多少錢呢？25元，還是40元？當然，是25元，而不是40元。這25元存儲在哪里呢？就是訂單快照表。我們在付款的那一刻，不管是直接購買的付款，還是從購物車中的購買，就會生成一條訂單材料快照表。快照表有哪些信息：一個購物車的外鍵，訂單的外鍵，裝修材料的中必須讓用戶知道的信息等。裝修材料從某種意義上來說，其也是一種一對一的關系，商品和快照找那個所存儲的主要的材料信息。

所有的信息，如以下代碼。不重要的或設計公司機密的信息，就不在這里展示了。

用戶表

這里用戶可以為分材料商和經銷商，通過這個枚舉類CustomerTypeEnum確定的。材料商和經銷商放在同一張表中，根據他們的類型，來確認是材料商和經銷商。

@Entity
@Table(name = "core_user")
public class User{

    /**
     * 用戶名，唯一
     */
    @NotEmpty(message = "用戶名不能為空")
    @Column(length = 100, unique = true, nullable = false)
    private String username;

    /**
     * 密碼
     */
    @Column(nullable = false, length = 66)
    private String password;

    /**
     * 最近登錄ip
     */
    @Column(name = "last_login_ip", length = 64)
    private String lastLoginIP;
    
   。。。。

材料商材料

因為材料商是一個實體，我們這里只要關聯材料商的外鍵即可，而且還是一對多的關系。因為，材料表中某一個材料商的記錄不止一條。其次，還要有材料類型，材料類型表是樹結構的，類型下面還有子類型。這里也是一對多的關系。

public class Material extends BaseObj {

    /**
     * 所屬品類
     */
    @ManyToOne
    @JoinColumn(name = "material_category_id")
    private MaterialCategory materialCategory;

    /**
     * 名稱
     */
    private String name;

    /**
     * 供應商
     */
    @ManyToOne
    @JoinColumn(name = "supplier_id")
    private Supplier supplier;

    /**
     * 品牌
     */
    @ManyToOne
    @JoinColumn(name = "material_brand_id")
    private MaterialBrand materialBrand;

    /**
     * 成本價
     */
    @Column(name = "cost_price", precision = 12, scale = 2)
    private BigDecimal costPrice;

    /**
     * 零售價
     */
    @Column(name = "retail_price", precision = 12, scale = 2)
    private BigDecimal retailPrice;

    /**
     * 單位
     */
    @ManyToOne
    @JoinColumn(name = "unit_code")
    private DataDict unit;
    
    。。。
}

經銷商材料

經銷商從材料商那邊購買了材料，經銷商的材料即來源于材料這張表。因而，這個經銷商材料只要關聯材料表即可。同時，還要有確認經銷商是哪個經銷商，因而，需要一個用戶的外鍵，即經銷商材料的所有者。經銷商有自己的定價規則，他需要定義一個市場價。

public class UserMaterial extends BaseObj {

    /**
     * 材料
     */
    @ManyToOne
    @JoinColumn(name = "material_id")
    private Material material;

    /**
     * 所有者
     */
    @ManyToOne
    @JoinColumn(name = "owner_id")
    private User owner;

    /**
     * 市場價
     */
    @Column(name = "market_price", precision = 12, scale = 2)
    private BigDecimal marketPrice;

   。。。
}

訂單

我們從經銷商那邊購買了材料，此時，有條購買記錄，這就是訂單。誰發起的訂單，也就是說，誰購買的這個材料，因而，需要用戶的外鍵。

public class Order extends BaseObj {

    /**
     * 收貨地址
     */
    @ManyToOne
    @JoinColumn(name = "work_site_id")
    private WorkSite workSite;

    /**
     * 訂單編號
     */
    @Column(name = "order_no")
    private String orderNo;

    /**
     * 訂單狀態
     */
    @Enumerated(EnumType.STRING)
    private OrderStatusEnum status;

    /**
     * 訂單備注
     */
    @Column(name = "remark", columnDefinition = "longtext")
    private String remark;

    /**
     * 下單時間
     */
    @Column(name = "generate_time")
    private Date generateTime;

    /**
     * 提交時間
     */
    @Column(name = "submit_time")
    private Date submitTime;

    /**
     * 買家
     */
    @ManyToOne
    @JoinColumn(name = "buyer_id")
    private User buyer;

購物車

我們已經選好了材料，但還沒有確認付不付款，于是，先在購物車存著，想起來就付款。加入到購物車的材料是經銷商的材料，因而，購物車需要存儲經銷商的外鍵。同時，還要確認是誰加入的購物車，因而購物車需要用戶的外鍵。這都是一對多的關系。同時，需要確認，這個購物車是否被使用。

public class ShoppingCart extends BaseObj {

    /**
     * 用戶材料
     */
    @ManyToOne
    @JoinColumn(name = "user_material_id")
    private UserMaterial userMaterial;

    /**
     * 數量
     */
    @Column(name = "num", precision = 12, scale = 2)
    private Double num = 1.0;

    /**
     * 金額
     */
    @Column(name = "amount", precision = 12, scale = 2)
    private BigDecimal amount;

    /**
     * 所有者
     */
    @ManyToOne
    @JoinColumn(name = "owner_id")
    private User owner;

    /**
     * 是否被使用
     */
    @Enumerated(EnumType.STRING)
    @Column(name = "is_used")
    private BooleanEnum isUsed = NO;
}

訂單材料快照表

這里，我們只要存儲訂單快照的id，而不是訂單快照的對象？為什么呢？首先，對于用戶來說，購買裝修材料時，這個購物車是不常用的，因為，他們一旦看中了，就會直接購買的。其次，如果我們存儲的是對象，用戶每次加載購物車時，都要從數據庫中遍歷當前id的購物車的數據庫的字段值，然后通過hibernate的反射封裝到購物車的對象中。所以說呢，無疑是減緩了效率，這樣不好。

需要訂單的外鍵，訂單和訂單快照雖然是一對一的關系，一個訂單一個訂單快照。也就是說，當用戶生成訂單時，就會有個訂單快照。用戶查看其購買記錄（訂單記錄）的材料信息時，材料信息不是來源于用戶材料表，而是來源于用戶訂單快照表。還有，用戶退還材料時，經銷商要查看用戶當前購買的材料信息。這就用到了訂單材料快照表。

public class OrderMaterialSnapshot extends BaseObj {

    /**
     * 購物車id
     */
    @Column(name = "shopping_cart_id")
    private Long shoppingCartId;

    /**
     * 訂單
     */
    @ManyToOne
    @JoinColumn(name = "order_id")
    private Order order;

    /**
     * 狀態
     */
    @Enumerated(EnumType.STRING)
    @Column(name = "status")
    private OrderMaterialStatusEnum status;

    /**
     * 購買數量
     */
    @Column(name = "num", precision = 12, scale = 2)
    private Double num = 1.0;

    /**
     * 退貨數量
     */
    @Column(name = "refund_num")
    private Double refundNum = 0.0;

    /**
     * 購買總金額
     */
    @Column(name = "amount", precision = 12, scale = 2)
    private BigDecimal amount;

    /**
     * 接單時間
     */
    @Column(name = "receive_time")
    private Date receiveTime;

    /**
     * 發貨時間
     */
    @Column(name = "deliver_time")
    private Date deliverTime;

    /**
     * 收貨時間
     */
    @Column(name = "receipt_time")
    private Date receiptTime;

    /**
     * 所屬品類
     */
    @ManyToOne
    @JoinColumn(name = "material_category_id")
    private MaterialCategory materialCategory;

    /**
     * 名稱
     */
    private String name;

    /**
     * 品牌
     */
    @OneToOne
    @JoinColumn(name = "material_brand_id")
    private MaterialBrand materialBrand;

    /**
     * 型號
     */
    private String model;

    /**
     * 零售價
     */
    @Column(name = "retail_price", precision = 12, scale = 2)
    private BigDecimal retailPrice;

    /**
     * 會員單價(材料商零售價*會員折扣)
     */
    @Column(name = "vip_unit_price", precision = 12, scale = 2)
    private BigDecimal vipUnitprice;

    /**
     * 市場價
     */
    @Column(name = "market_price", precision = 12, scale = 2)
    private BigDecimal marketPrice;

    /**
     * 單位
     */
    @ManyToOne
    @JoinColumn(name = "unit_code")
    private DataDict unit;
    
    。。。

}

總結

要想稱為優秀的架構師，首先參考別人的架構，畢竟，他山之石，可以攻玉嗎！！！

再接再厲，致奮斗的自己！！！

數據方舟 UDataArk 磁盤快照服務 USnap php商品訂單系統訂單表里添加商品id 購物車商品增加php php的商品收藏

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/73677.html

50個關于MongoDB模型設計的技巧

摘要：另一個時間點的一致性很重要，對于難以協調不一致的應用程序。應該將模式設計為按應用程序單元進行查詢。＃1：速度優先使用嵌入數據，完整性優先使用引用數據多個文檔使用的數據可以使用嵌入（非規范化）或引用（規范化）。非規范化并不一定比規范化更好，反之亦然：每種方式都有自己的權衡，你應該選擇最適合你的應用程序的方式。非規范化可能導致數據不一致：假設您想要將圖1-1中的蘋果更改為梨。如果更新...

sf190404 2019-06-26 17:53 評論0 收藏0
Laravel 教程 - 實戰 iBrand 開源電商 API 系統

摘要：最佳實踐良好的編碼規范單元測試持續集成文檔，從一開始就形成良好的編碼習慣。真實的電商業務所有的業務需求來自真實的客戶，并且線上良好運營中。重要通知： Laravel + 小程序的開源電商版本源碼已經在 github 上拉，歡迎提交 issue 和 star :) 開源電商 Server 端: Laravel API源碼開源電商 client 端：小程序源碼 iBrand 簡介...

iOS122 2019-06-28 18:26 評論0 收藏0
PHP面試題

摘要：質量高在設計時，可重用現有的，在以前的項目的領域中已被測試過的類使系統滿足業務需求并具有較高的質量。代碼塊捕獲異常，并創建一個包含異常信息的對象。這樣可以解決超賣的問題，但是會導致文件得開銷很大。 6.你們公司是使用什么框架? 答:我們公司采用的是TP框架,運用的mysql+apache+php進行開發,因為TP框架是一個免費開源的,輕量級的php開發框架,而且是我們中國人自己開發的,...

ls0609 2019-07-01 11:19 評論0 收藏0
UML統一建模語言

摘要：什么是全稱是又稱統一建模語言或標準建模語言。于是乎，為了統一起來，就有了組織對象管理組織，這個組織讓這種描述需求設計的語言統一了，就稱作是了。什么是UML？ UML全稱是：Unified Modeling Language 又稱統一建模語言或標準建模語言。是一個支持模型化和軟件系統開發的圖形化語言，為軟件開發的所有階段提供模型化和可視化支持，包括由需求分析到規格，到構造和配置。它是...

ninefive 2019-08-15 14:35 評論0 收藏0