㈠ 電子商務系統設計。
我們公司在品拓互聯做過一個企業網站和推廣，服務跟售後都挺好的，可以提供上門服務，都是他們專員到我們公司來解決處理問題，感覺還挺方便的，是國內一家知名網站建設推廣公司，他們的客戶專員對互聯網的操作還有資訊都很到位的，不做網站咨詢下他們網路營銷還是挺好的，能學到很多新東西，呵
㈡ 請教有電子商務（網上商城）設計經驗的高手，關於促銷策略資料庫設計
我給企業做過許多電子商務網站，活動促銷是每個網上商城必須有的，我就講下，我對活動促銷的開發設計方法吧。
我的促銷方式有：全場免郵費或滿額免郵費、分層級滿額贈禮品、限時折扣促銷、買就贈等
首先要明確每種活動的性質：
1、全場免郵費或滿額免郵費，滿額贈禮品、買就贈（訂單）等這種形式是一種訂單活動；
2、限時折扣、打折促銷、買1贈1、買就贈（單品）等形式是單品活動；
那有上面兩種形式後我們就容易來處理了，訂單活動，我們只需要建設一個資料庫表設置活動的形式及滿額的額度還有分級及禮品就可以了，然後客戶下訂單後，我們從訂單裡面來處理這個活動；
第二種單品活動，我們就要從單品上來處理，兩種形式，1直接從產品表裡面設置，前台讀取後判斷設置該產品是否活動開啟；2單獨創建活動表，設置活動形式，產品編號等相關信息欄位，然後從活動頁面讀取這些信息即可。
我不知道我的回答是不是滿足你的需求，我們可以多溝通下。
㈢ 電子商務網站的資料庫設計
一個資料庫的設計，決不是你說的這些。就沖你說的這些，說明你對需求都沒怎麼明白。
資料庫設計，需要設計師參透需求。其次才是ER設計。
別一上來就弄表。悠著點。
㈣ 求一個電子商務資料庫設計步驟
一般，資料庫的設計過程大致可分資料庫設計為5個步驟：
(1)需求分析；調查和分析用戶的業務活動和數據的使用情況，弄清所用數據的種類、范圍、數量以及它們在業務活動中交流的情況，確定用戶對資料庫系統的使用要求和各種約束條件等，形成用戶需求規約。
(2)概念設計；對用戶要求描述的現實世界(可能是一個工廠、一個商場或者一個學校等)，通過對其中住處的分類、聚集和概括，建立抽象的概念數據模型。這個概念模型應反映現實世界各部門的信息結構、信息流動情況、信息間的互相制約關系以及各部門對信息儲存、查詢和加工的要求等。所建立的模型應避開資料庫在計算機上的具體實現細節，用一種抽象的形式表示出來。以擴充的實體——聯系模型方法為例，第一步先明確現實世界各部門所含的各種實體及其屬性、實體間的聯系以及對信息的制約條件等，從而給出各部門內所用信息的局部描述(在資料庫中稱為用戶的局部視圖)。第二步再將前面得到的多個用戶的局部視圖集成為一個全局視圖，即用戶要描述的現實世界的概念數據模型。
(3)邏輯設計；主要工作是將現實世界的概念數據模型設計成資料庫的一種邏輯模式，即適應於某種特定資料庫管理系統所支持的邏輯數據模式。與此同時，可能還需為各種數據處理應用領域產生相應的邏輯子模式。這一步設計的結果就是所謂「邏輯資料庫」。
(4)物理設計；根據特定資料庫管理系統所提供的多種存儲結構和存取方法等依賴於具體計算機結構的各項物理設計措施，對具體的應用任務選定最合適的物理存儲結構(包括文件類型、索引結構和數據的存放次序與位邏輯等)、存取方法和存取路徑等。這一步設計的結果就是所謂「物理資料庫」。
(5)驗證設計；在上述設計的基礎上，收集數據並具體建立一個資料庫，運行一些典型的應用任務來驗證資料庫設計的正確性和合理性。一般，一個大型資料庫的設計過程往往需要經過多次循環反復。當設計的某步發現問題時，可能就需要返回到前面去進行修改。因此，在做上述資料庫設計時就應考慮到今後修改設計的可能性和方便性。
㈤ 電子商務網站資料庫設計急
放到一個抄表是不現實的。我襲在學校做的練習中，
應該是每種商品一個表，而且還應抽取出商品的共有屬性，設計 顏色表、商品規格表、商品價格表等等。這樣當增加一款商品，這款商品有不同顏色時，在該商品表中只需增加一條數據。在顏色表中添加多條，用多對一，減少大量冗餘數據。
而像 作者 出版社這些屬性，直接寫在『book』表中作為欄位就成了。
為了view層抽取數據時方便，應有 』分類表『 比如說 電腦、剃須刀等，歸為電子類。
剩下的就是 用戶表 訂單表（訂單表中，應以商品id+商品顏色id+價錢id等等來唯一確定一個商品），基本各一張就搞定了。
㈥ 電子商務的交易記錄，資料庫怎麼設計
首先來說對於這種場景有兩種設計方法，這兩種方法都能夠滿足擴展性要求
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會比麻煩，也影響性能。
㈦ 電子商務網站資料庫設計時，商品表如何設計的問題
你開始並沒有說清楚
按你的最新要求，應該是：
一個商品表，一個屬性表（欄位不重專復了）
然後就是賣家商品屬表，欄位如下：
賣家id 商品id 商品數量
明白嗎？
如果多個店賣同一種商品，那數據都在賣家商品表裡
需要商品名時，從商品表關聯取數據，
需要商品屬性時，從屬性表關聯
你想的復雜了
就2個表，一個商品表，一個屬性表
商品表欄位：id 品名
屬性表欄位：商品id 屬性名 屬性值
也就是說一個屬性一條記錄
㈧ 電子商務MySql數據表設計問題，比如：一個商品有多個價位怎麼設計數據表保存就像一個商品有大中小
我朋友的公共號就是關於電商的類容，可以跟裡面的朋友請教。掃我簽名檔
㈨ 電子商務產品資料庫設計
這是一個非常好的問題！不過已經把解決方案給出來了。
我的理解是"動態回表結構"。
Proct(p_id,name)
ExtendField(ef_id,name,p_id)
ExtendValue(ev_id,value,ef_id,p_id)
當添加新屬性時，只答是相當於在資料庫添加一條記錄，沒有該變表結構。
這里是存的是書，現在要存儲英譯書(原作者，譯者，原出版社，國內出版社)
這就中文書籍不需要原作者、原出版社，如果為了存儲英譯書，只需向後2個表添加記錄即可，否則就要向proct表添加2個屬性，而該設計不必改變原表的表結構(table schema)。