第三篇了，fighting！！！！
這上面的部大部分資料都已經存放在資料庫中了，但是還有一些小問題，就是運費的計算，如果商家不包郵，怎麼計算運費的情況？
前面我們只設計了產品列表，我們這裡引入乙個新的表，商家表，商家表設計如下：
sellerid
seller_name
positionid 下面的地理位置的表
banner_src 中間那個橫幅廣告
products 包含商品，在糾結是否在產品表中新增這個字段，但是想想還是算了，我不打算做店鋪的頁面
express 商家支援的快遞 id
有了商家的位置 location 以及可以在客戶註冊的時候新增乙個預設收貨位址，還有商家支援的快遞種類，現在的問題是，不同的快遞種類怎麼根據距離收費的？我是打算自己建立一張表，根據這張表來計算運費了，因為就算快遞公司有提供介面給我，我也弄不到授權
expressid
pxpress_name
per_metre 每公尺**
per_g 每克，別問為什麼不是每斤
parent_expressid 總感覺以後會有用
這裡的運費計算方式是把中國的地理位置的經緯度作為二維陣列存放在另外一張表中：
positionid
long
lat
position_name
之後所有的地理位置都要從這張表裡讀取，根據經度和緯度計算直線距離，之後根據每公尺和每克的收費標準計算運費，而且全國都可達
運費搞定之後就是下面的
產品詳情介紹
這裡我打算在後台讓買家輸入標籤的形式進行儲存，之後轉化成 json 格式存入 mongodb 中，這點到時不難做到。下面就是無止境的廣告了，到時候也讓買家自己去加個夠吧。。。。。。。
從上面我們看出還有一張表訂單表
orderid
customerid
date
又要建立一張客戶表。。。。
customerid
customer_name
birthday
password
positionid
telephone
還有一張訂單詳情表，我也不知道為什麼不把這張表合併到訂單表中前面乙個專案留下的後遺症吧：
orderid
productid
quantity
根據前台設計資料庫 搜尋頁篇
那裡的篩選條件，第乙個篩選條件一定是品牌，這個品牌當然需要一張表來進行儲存，那是為了後台管理方便，但是這裡不是從這張表中讀取的，而是從產品列表中讀取，現在的構想是 select distinct provider.provider name from provider,product where p...
設計資料庫
當資料庫比較複雜時 資料量大，表較多，業務關係複雜 需要預先設計資料庫。軟體專案的開發周期 1.需求分析 分析客戶的業務和資料處理需求 2.概要設計 設計資料庫的e r模型圖，確認需求資訊的正確和完整 3.詳細設計 將e r圖轉換為多張表，進行邏輯設計，並用資料庫設計的三大正規化進行審核 4.編寫 ...
資料庫設計 設計資料庫之前
1.考察現有環境 在設計乙個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫 專案都不是從頭開始建立的 通常，機構內總會存在用來滿足特定需求的現有系統 可能沒有實 現自動計算 顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究 可以讓你發現一些可能會忽略...