⑴ 關於電商網站資料庫的設計有什麼好的建議
這個問題的核心點在於：不同商品類別差異很大，如何設計通用的存儲方案？簡單來說，用資料庫去存儲所有信息，不管橫表還是縱表，都有明顯的缺陷：橫表：同一個欄位對不同商品含義不一樣，這到了後面開發和維護是很蛋疼的縱表：一個商品的屬性分布到很多行記錄中，業務處理很麻煩，而且縱表的記錄數會非常多，性能會有問題所以不要嘗試只用資料庫去統一解決這個問題，思路擴散一些其實就簡單了：公共表：提煉商品公共的信息放到資料庫，例如商品id、名稱、發布的商家、發布日期、上架狀態擴展表：將變化的信息放到另外一個表，可以是資料庫表，例如電腦商品一個表、服裝一個表；也可以將信息放到MongoDB或者ElasticSearch這類文檔資料庫。搜索組件：擴展表在全文搜索的時候不好實現，因此需要獨立的組件負責搜索，可以用Elastic Search或者Solr來冗餘一份數據，用於搜索。表結構不算復雜，因為項目關系只有SPU，沒有涉及到SKU，但是可以做參考，更多的還是要根據項目實際情況設計。重點說明一下產品表的SPU，Keyword欄位。本來之前設計了關系表，但是發現在做SQL查詢時太痛苦，所以約定了一種數據存儲結構（數據結構的重要性）基於上面的基礎，可以實現URL規則變化的查詢,類似京東的產品查詢URL變化c=1,3 指分類層次關系ev=3_1+4_18 指SPU查詢 按約定規則轉換成字元串再進行查詢。
⑵ 電子商務的交易記錄，資料庫怎麼設計
首先來說對於這種場景有兩種設計方法，這兩種方法都能夠滿足擴展性要求
1. 把原有的橫表轉化為縱表存儲屬性，即
產品表：（proct_id, proct_name, proct_class)
產品屬性表：(proct_id, property_id , property_name , property_value)
2. 保持原有橫表設計思路，但是彈性欄位含義單獨元數據表存儲
產品表：（proct_id, proct_name, proct_class, prop1, prop2, .... propn)
產品屬性含義元數據表
(proct_class , prop1_name ,prop2_name, ..... propn_name)
對於兩種設計方法，個人理解為
a. 對於首頁打開就必須要能夠快速查詢出來的屬性，而且這些屬性本身各類產品差異不大。而對於差異大的屬性基本都是針對特定一個產品查詢。可以採用方案1來做。
b. 首頁顯示產品列表時候就存在要顯示出不同產品屬性情況，採用方案2來做。當我們處理的是一個proct list的時候，由於存在數據表本身的關聯場景，用方案1會比麻煩，也影響性能。
⑶ 電商項目---資料庫表設計
CREATE TABLE `mmall_user` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用戶表id',
`username` varchar(50) NOT NULL COMMENT '用戶名',
`password` varchar(50) NOT NULL COMMENT '用戶密碼，MD5加密',
`email` varchar(50) DEFAULT NULL,
`phone` varchar(20) DEFAULT NULL,
`question` varchar(100) DEFAULT NULL COMMENT '找回密碼問題',
`answer` varchar(100) DEFAULT NULL COMMENT '找回密碼答案',
`role` int(4) NOT NULL COMMENT '角色0-管理員,1-普通用戶',
`create_time` datetime NOT NULL COMMENT '創建時間',
`update_time` datetime NOT NULL COMMENT '最後一次更新時間',
PRIMARY KEY (`id`),
UNIQUE KEY `user_name_unique` (`username`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=22 DEFAULT CHARSET=utf8;
CREATE TABLE `mmall_proct` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '商品id',
`category_id` int(11) NOT NULL COMMENT '分類id,對應mmall_category表的主鍵',
`name` varchar(100) NOT NULL COMMENT '商品名稱',
`subtitle` varchar(200) DEFAULT NULL COMMENT '商品副標題',
`main_image` varchar(500) DEFAULT NULL COMMENT '產品主圖,url相對地址',
`sub_images` text COMMENT '圖片地址,json格式,擴展用',
`detail` text COMMENT '商品詳情',
`price` decimal(20,2) NOT NULL COMMENT '價格,單位-元保留兩位小數',
`stock` int(11) NOT NULL COMMENT '庫存數量',
`status` int(6) DEFAULT '1' COMMENT '商品狀態.1-在售 2-下架 3-刪除',
`create_time` datetime DEFAULT NULL COMMENT '創建時間',
`update_time` datetime DEFAULT NULL COMMENT '更新時間',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=30 DEFAULT CHARSET=utf8;
CREATE TABLE `mmall_category` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '類別Id',
`parent_id` int(11) DEFAULT NULL COMMENT '父類別id當id=0時說明是根節點,一級類別',
`name` varchar(50) DEFAULT NULL COMMENT '類別名稱',
`status` tinyint(1) DEFAULT '1' COMMENT '類別狀態1-正常,2-已廢棄',
`sort_order` int(4) DEFAULT NULL COMMENT '排序編號,同類展示順序,數值相等則自然排序',
`create_time` datetime DEFAULT NULL COMMENT '創建時間',
`update_time` datetime DEFAULT NULL COMMENT '更新時間',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=100031 DEFAULT CHARSET=utf8;
CREATE TABLE `mmall_order` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '訂單id',
`order_no` bigint(20) DEFAULT NULL COMMENT '訂單號',
`user_id` int(11) DEFAULT NULL COMMENT '用戶id',
`shipping_id` int(11) DEFAULT NULL,
`payment` decimal(20,2) DEFAULT NULL COMMENT '實際付款金額,單位是元,保留兩位小數',
`payment_type` int(4) DEFAULT NULL COMMENT '支付類型,1-在線支付',
`postage` int(10) DEFAULT NULL COMMENT '運費,單位是元',
`status` int(10) DEFAULT NULL COMMENT '訂單狀態:0-已取消-10-未付款，20-已付款，40-已發貨，50-交易成功，60-交易關閉',
`payment_time` datetime DEFAULT NULL COMMENT '支付時間',
`send_time` datetime DEFAULT NULL COMMENT '發貨時間',
`end_time` datetime DEFAULT NULL COMMENT '交易完成時間',
`close_time` datetime DEFAULT NULL COMMENT '交易關閉時間',
`create_time` datetime DEFAULT NULL COMMENT '創建時間',
`update_time` datetime DEFAULT NULL COMMENT '更新時間',
PRIMARY KEY (`id`),
UNIQUE KEY `order_no_index` (`order_no`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=118 DEFAULT CHARSET=utf8;
CREATE TABLE `mmall_order_item` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '訂單子表id',
`user_id` int(11) DEFAULT NULL,
`order_no` bigint(20) DEFAULT NULL,
`proct_id` int(11) DEFAULT NULL COMMENT '商品id',
`proct_name` varchar(100) DEFAULT NULL COMMENT '商品名稱',
`proct_image` varchar(500) DEFAULT NULL COMMENT '商品圖片地址',
`current_unit_price` decimal(20,2) DEFAULT NULL COMMENT '生成訂單時的商品單價，單位是元,保留兩位小數',
`quantity` int(10) DEFAULT NULL COMMENT '商品數量',
`total_price` decimal(20,2) DEFAULT NULL COMMENT '商品總價,單位是元,保留兩位小數',
`create_time` datetime DEFAULT NULL,
`update_time` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `order_no_index` (`order_no`) USING BTREE,
KEY `order_no_user_id_index` (`user_id`,`order_no`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=135 DEFAULT CHARSET=utf8;
CREATE TABLE `mmall_cart` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) NOT NULL,
`proct_id` int(11) DEFAULT NULL COMMENT '商品id',
`quantity` int(11) DEFAULT NULL COMMENT '數量',
`checked` int(11) DEFAULT NULL COMMENT '是否選擇,1=已勾選,0=未勾選',
`create_time` datetime DEFAULT NULL COMMENT '創建時間',
`update_time` datetime DEFAULT NULL COMMENT '更新時間',
PRIMARY KEY (`id`),
KEY `user_id_index` (`user_id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=127 DEFAULT CHARSET=utf8;
CREATE TABLE `mmall_pay_info` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) DEFAULT NULL COMMENT '用戶id',
`order_no` bigint(20) DEFAULT NULL COMMENT '訂單號',
`pay_platform` int(10) DEFAULT NULL COMMENT '支付平台:1-支付寶,2-微信',
`platform_number` varchar(200) DEFAULT NULL COMMENT '支付寶支付流水號',
`platform_status` varchar(20) DEFAULT NULL COMMENT '支付寶支付狀態',
`create_time` datetime DEFAULT NULL COMMENT '創建時間',
`update_time` datetime DEFAULT NULL COMMENT '更新時間',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=61 DEFAULT CHARSET=utf8;
CREATE TABLE `mmall_shipping` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) DEFAULT NULL COMMENT '用戶id',
`receiver_name` varchar(20) DEFAULT NULL COMMENT '收貨姓名',
`receiver_phone` varchar(20) DEFAULT NULL COMMENT '收貨固定電話',
`receiver_mobile` varchar(20) DEFAULT NULL COMMENT '收貨行動電話',
`receiver_province` varchar(20) DEFAULT NULL COMMENT '省份',
`receiver_city` varchar(20) DEFAULT NULL COMMENT '城市',
`receiver_district` varchar(20) DEFAULT NULL COMMENT '區/縣',
`receiver_address` varchar(200) DEFAULT NULL COMMENT '詳細地址',
`receiver_zip` varchar(6) DEFAULT NULL COMMENT '郵編',
`create_time` datetime DEFAULT NULL,
`update_time` datetime DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=30 DEFAULT CHARSET=utf8;
GitHub 地址：https://github.com/Andy-leoo/NewBieJavaPro.git
⑷ 電商訂單系統設計原理主要用了什麼技術
電子商務系統的總體結構設計是在系統體系結構的基礎上，針對企業電子商務的目標，界定系統的外部邊界和介面，刻畫系統的內部成及其相互關系，明確目標系統的各個組成部分、各個組成部分的作用及其相互關系。 系統總體結構設計包括如下內容： 1．確定系統的外部介面 通過分析，將電子商務系統與其外部環境區分開來，從而使總體設計有一個明確的范圍。系統與其外部環境的介麵包括以下方面： （1）與企業合作夥伴之間的介面； （2）與企業內部既有信息系統的介面； （3）與交易相關的公共信息基礎設施之間的介面； （4）其他介面如態爛，如企業與政府或其他機構之間的介面。 2．確定系統的組成結構 系統組成結構主要說明目標系統內部的組成部分，以及系統內部與外部環境的相互關系。 方法： 隨著Internet技術的發展，人們的日常生活已經離不開網路。未來閉陪社會人們的生活和工作將越來越依賴於數字技術的發展，越來越數字化、網路化、電子化、虛擬化。電子商務也隨著網路的發展日益和人們的生活貼近。本設計嘗試用ASP在網路上架構一個動態的電子商務網站，以使每一位顧客不用出門在家裡就能夠通過上網來輕松購物。在本設計中，我主要完成了後台功能的實現，實現了登錄功能，圖書管理，圖書分類管理，訂單管理，用戶管理等功能。 本文中所做的主要工作如下： (1)簡單介紹了電子商務，分析了電子商務的現狀； (2)介紹了IIS+ASP系統的一般原理； (3)闡述整個系統的系統結構及工作原理；分析了系統實現中的特殊性、難點和重點； (4)分析並解決實現中的若干技術問題； 附： 方案設計主要依靠設計者的經驗，作出技術和結構的選擇，並以有組織的文檔反映，作為與客戶交流論證方案，交付系統開發人員實施的依據，方案設計的基礎是業務環境說明書。業務環境說明書重新組織系統需求，給出解決方案的業務運作方式。在系統需求相對簡單時不一定需要，如果系統需求較為復雜時，以文字和圖表的方式系統地說明業務環境可以使系統需求更加清楚，業務環境說明書可以採用三種文檔結構。 * 業務流程圖：業務流程圖描述企業的業務在新系統中如何運作，說明新系統的業務運作模式如何解決客戶的要求，指出客戶的業務流程因為新系統的應用而作出那些更改。業務流程圖是一種直觀的工具，向客戶解釋新系統的作用，徵求使用者的配合與支持，能提高新系統的實際效能。 * 操作規程說明：相對於業務流程圖這種較高層概括的文檔，普通用戶可能更需要一份詳細的操作規程說明，以便更好地理解系統的功能與使用。操作規程說明以易被最終用戶理解的詞語描述，避免使用過分專業的詞語。操作規程說明仍屬於高層設計文檔，不是最終的操作步驟說明。操作規程說明規定了系統活動的框架， * 處理流程圖 ： 細化操作規程中描述的活動，由事件和處理流組成。事件是活動開始的條件，處理是活動中的具體工作。處理流程圖的描述層次接近詳細設計。以客戶在網上購貨為例，最後一步是確認付款，操作規程說明只需簡單地說明：「客戶檢查付款額後確認」，處理流程圖的說明比較詳細，激發活動的事件是客戶按下「付額」按鈕，處理是付款總額從資料庫中統計出來，顯示在瀏覽器上，最後由客戶按「確認」按鈕確認。 當前普遍採用對象技術描述復雜的應用結構，電子商務系統一般用Java,EJB,CORBA等對象技術實現，在系統設計階段，編制業務環境書時採用面向對象分析和設計方法可以提高實施階段的效率。業務環境說明書中的設計文檔完成後，召開第二次項目會議，在會上以圖表的形式向客戶和項目開發人員介紹系統設計的概貌。著重與客戶討論兩個問題，檢查系統設計是否滿足客戶需求： 系統設計在多大程度上解決了用戶的需求？是否准確地實現了客戶的期望，既沒有過分簡單化，也沒有過分復雜化。 系統設計的功能范圍是否包含了用戶提出的所有需求？ 應用開發人員參加項目會議，可以更好地了解客戶的業務環境與方案設計的總體結構，與客戶和系統設計者直接交談，減少溝通的誤差，提高效渣漏率。 IBM為電子商務系統定義了一套完整的電子商務應用框架，基於三層次體系結構集成企業核心系統與互聯網服務，多層次結構使企業內部應用系統無需作重大更改，通過與互聯網伺服器的連結就可以在互聯網上提供服務，實現電子商務系統的目標。 基於電子商務應用框架的電子商務系統體系結構共有八個主要部分。直接支持應用程序運行的模塊有六個：客戶端、網路連接、互聯網伺服器、應用邏輯、中間連接件、核心數據與應用，其餘兩個模塊安全性和系統管理與這六個模塊都有關聯，系統設計者可相對獨立地設計安全性體系和系統管理體系，在應用程序運行支持模塊的實現中加入相應的技術與處理。安全性和系統管理的效率是系統的整體性效果，應用系統運行的每一個環節都能影響系統總體的安全性和可管理性。