那裡的篩選條件，第乙個篩選條件一定是品牌，這個品牌當然需要一張表來進行儲存，那是為了後台管理方便，但是這裡不是從這張表中讀取的，而是從產品列表中讀取，現在的構想是：
select distinct provider.provider_name from provider,product where provider.providerid = product.providerid limit 0,20 order by product.salary
從上面來看，產品表還需要再額外新增兩個字段：providerid 和 salary ，前者不用說，後者是總銷量，這個總銷量要怎麼存呢？前面我們拿 mongodb 來進行儲存銷售情況，但是我們忽略了一張表，那就是庫存表，其實庫存表要儲存的情況和銷售表是結構是一致的，那麼我們能不能嘗試將庫存表存放在銷售表中呢？
當然可以，誰讓 json 沒有固定的格式呢：
db.salary.insert(,
].......其他顏色情況..........
其中在每個記錄下新增一條記錄：store 以及 salary 記錄，記錄產品各個型號的庫存數量以及銷售情況，因為對於一筆交易，庫存數量的減少與銷量的增加總是一起操作的。
這樣就解決了存放庫存以及銷售量的資料，回到原始的問題中來，這裡的總銷量就當作乙個字段儲存在產品表中吧，下面的篩選中也有按照銷量進行排序的，那裡也是重頭戲之一。
第乙個篩選條件是品牌，第二個呢？甚至接下來的第三個，第四個呢？這些就不能固定了，我的乙個想法是：無論是通過搜尋還是通過導航到達這乙個頁面的，必須為這個頁面傳入至少乙個引數：產品分類的 id，然後以此產品分類的 id 為根節點，選出他的子節點作為這裡導航條件，例如，搜尋 秋裝，以秋裝為節點，之後以他的下一級，例如，夾克，襯衫，t桖等作為乙個篩選條件，再搜尋此節點下的子分類作為乙個篩選條件，採取這樣的條件的話，怎麼確定總共要篩選多少級呢？可以看到**有的是3級，有的是4級，這樣怎麼確定呢？要不定義乙個上限，乙個下限，之後在這個上下限之間浮動？如果之後他的分類節點大於最大的限制數，就只顯示最大級數之前的，如果小於最大級數，那麼搜尋最完美，從**上可以看出這一點，例如我搜尋乙個很大的分類，如服裝：
會有乙個很大的分類：女 中性 男
但是下面為什麼是這種分類，理解不能了
篩選條件結束之後就是排序的那一行了，有按照綜合排序的，有按照人氣排序的，銷量啊，信用啊，這些肯定都要對應到產品表中的字段中去，那麼乙個乙個來解決。
從簡單的開始，銷量，有這個欄位了，**？這個新增乙個欄位也是容易的，但是我們知道有一種很坑的情況是，一般商家標**標籤會怎麼標？￥30-150，這個之後如果你將**的字段設定成 float 的話肯定就沒有辦法存了，更別說設定成 char 了，沒法用 order 。那麼應該怎麼辦呢？將這個也存進 mongodb 中？表示各個型號的不同**？肯定不行，因為很多多餘的資訊會讀出來，這樣造成額外的操作時間，有點不爽。而這個**的不同就是因為其中不同型號的**不同或者折扣的原因，所以如果有這種情況的話，這些資料肯定還要存放進 mongodb 中，但是現在首要的情況是解決這裡的**排序。我可以接受在產品中新增乙個**的字段，但是這個字段一定要是 float 型別的，所以我決定放棄這個形式的顯示 ￥134-150
還有人氣。。。。。人氣。。。。。什麼意思？銷量高的不就人氣高嗎？把這個刪了
信用，這個倒還是有點麻煩的，因為這牽扯到乙個評價的問題，即買家對這家店的評價也是乙個問題，肯定還有一張表，這張表我想這樣設計：
productid five_star four_star three_star two_star one_star unsatisfied
之後在產品表中新增乙個字段，計算乙個權重的值:
20%*（五星評價條數）+20%*（四星評價條數）+20%*（三星評價條數）+20%*（二星評價條數）+20%*（一星評價條數）-40%*（不滿意的評價）
最後乙個綜合排序
排序結束之後，就要來檢視下面的產品介紹了
看到有很多的小部件，首先，是否包郵，是否承擔運費險，是否是**，總之就是下面的那個小圖示，這個只要在產品表中新增乙個字段就行了
ok了，現在進行總結，資料庫進行修改如下：
product：productid product_name categoryid providerid salary_amount normal_price evaluate transport_free transport_insurence quality
category:categoryid category_name parent_categoryid
provider:providerid provider_name
comment:productid five_star four_star three_star two_star one_star unsatisfied
mongodb：
product_detail：除了在原先的分類上新增三個字段，庫存，銷量，售價
根據前台設計資料庫 產品展示頁
第三篇了，fighting！這上面的部大部分資料都已經存放在資料庫中了，但是還有一些小問題，就是運費的計算，如果商家不包郵，怎麼計算運費的情況？前面我們只設計了產品列表，我們這裡引入乙個新的表，商家表，商家表設計如下 sellerid seller name positionid 下面的地理位置的表...
設計資料庫
當資料庫比較複雜時 資料量大，表較多，業務關係複雜 需要預先設計資料庫。軟體專案的開發周期 1.需求分析 分析客戶的業務和資料處理需求 2.概要設計 設計資料庫的e r模型圖，確認需求資訊的正確和完整 3.詳細設計 將e r圖轉換為多張表，進行邏輯設計，並用資料庫設計的三大正規化進行審核 4.編寫 ...
資料庫設計 設計資料庫之前
1.考察現有環境 在設計乙個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫 專案都不是從頭開始建立的 通常，機構內總會存在用來滿足特定需求的現有系統 可能沒有實 現自動計算 顯然，現有系統並不完美，否則你就不必再建立新系統了。但是對舊系統的研究 可以讓你發現一些可能會忽略...