查看完整版本: 關於 資料庫的問題
頁: [1]

ww22511 發表於 2017-12-2 08:23 PM

關於 資料庫的問題

請問 我想建立一個資料庫
當然有 客戶 日期 和價錢 這些東西
但是 我想賣的東西 每天的價格都會變動的
那該怎麼辦?
不就每天都要去 物品的資料表 那邊去改價錢???

另外一個問題 :
例如 12月 2號 1之筆 30元 然後賣給了很多客戶
但  12月3號 1之筆變成 40元了  (所以 在物品的資料表 把筆價個改成40元)

但是 12 月 2號  要調出 那天的資料  可是物品資料表的價格 改成40元了
這樣 調出來 價錢不就都不一樣了嗎?
...<div class='locked'><em>瀏覽完整內容,請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div><div></div>

sheauren 發表於 2017-12-3 02:46 PM

1. 每一次產品價格變動都留下異動紀錄,沒異動就沿用原本價格就好
2. 如果記錄都是當天填入,拿成交直接拿最後價格直接紀錄[單價、總價都留],如果可能會後補價格,那異動紀錄可以讓你取得當時的價格來計算就好),調出當天資料因為單價、總價都存了,所以就不用去查產品價格那邊了

羕漾 發表於 2017-12-3 06:07 PM

關聯式資料庫好用的地方在這裡
你可能會有「商品」的資料庫,及「交易」的資料表(交易可能還會拆分成交易主體及商品的紀錄,這個看你怎作正規化)
作法可能會如下:
1. 增加一個價格歷史紀錄,裡面的欄位至少有商品編號、價格及價格生效時間
當商品價格有異動時你就可以回去對那個時間點生效的價格,就能得到你要的解了
這個方法有個好處是你可以額外得到一份價格歷史的紀錄,如果有要資料分析時可以拿來用
2. 於交易資料表的商品部份新增「單價」欄位,透過該欄位紀錄價格
這樣的好處是你只要檢索到交易紀錄,就可以直接得到單價,不需要花資源去串接商品的價格異動紀錄,找到你那時的價格
兩種方法主要是看你會需要的資料而定,如果你很確定之後不會需要精確的歷史價格紀錄,那選擇第 2 種方法會是較直覺的!...<div class='locked'><em>瀏覽完整內容,請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div>

kentcat3030 發表於 2017-12-29 05:52 PM

我覺得,對於資料的結構,樓主可能要多學習一些.
因為,你提的問題,算是資料結構基礎設定.

簡單的說
『賣的東西 每天的價格都會變動的』
這當然就要每天去更改價格,但不一定要去直接更改資料庫,
寫支小程式介面,去維護更改即可.
若是懶得自己改,而又有其他的地方(網站...等)可參考,
那就每天用程式去參考別處的價格,自動更改自己的價格.
(這又是另一層次的做法)

每次成交,加入『客戶 日期 和 成交價錢』的資料庫,
要調出 那天的資料,就以此資料庫搜尋,就好了 ^_^...<div class='locked'><em>瀏覽完整內容,請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div>

w12463 發表於 2018-1-23 06:36 PM

給個思路 價格=原價+當日異動價  若沒異動那異動價=0
然後還是要去管理每天的異動價 好處是任何一天的價格都有記錄
不然就KEY=客戶+生效日期 有新價時就把舊價停用就可了<br><br><br><br><br><div></div>

longbest 發表於 2018-4-6 12:15 AM

以簡單的系統來説,商品資料的單價只會影響新開出貨單的商品價格
不管價格怎麼變化,基本上都是用出貨單來紀錄實際銷售單價
因為收錢/付錢都是以此為憑證

love88131496 發表於 2018-7-13 02:39 PM

商業交易的系統實作設計,用這個方向來設計,減少未來不同情況,才發現當初設計要變更:

所有系統的資料,區分為三類:

1. 基本型: 例如商品的基本資料、客戶的基本資料。這些定義型的資料有個特色: 不是跟據客戶的活動去變更或增加,而是跟據商家的需求、擴充等等才去異動
2. 交易型: 例如訂單、採購單、出貨單、驗收單等資料。這些交易型的資料有個特色: 是因為客戶的活動去變更或增加。這些資料的量會非常大
3. 定義型: 整體系統要用的基礎資料。例如: 角色、權限等等。這些資料有個特色: 就是系統一上線時就得設定好的"最基本資料",否則程式根本一開什麼都不能動。

相對於資料庫理論,這三種類別的資料應用的觀念不同:
1. 基本型資料採用正規化設計,交易型"絕對不要用正規化設計",定義型無妨
2. 和"過去時間"有關的設計,一定是交易型,所以不要用正規化,一律"開欄位從基本型資料表抄過來"
3. 和"最新"有關的,就不一定。

採用這些原則來設計,就算一開始認為不會有這問題,將來也有可能會遇到,例如本PO的問題就是常見的例子。

範例: 商店有賣多種商品,每種商品有圖片、價格、庫存數量、其它描述資料。客戶下訂單,有客戶基本資料、訂單、付款取貨資料。

分析:
商品圖片: 只有顯示用途,所以是基本型資料
價格: 會不同,可能會打折等等。但客戶買產品只會顯示目前價格,所以可屬基本資料
庫存資料: 相同於價格

訂單、付款資料: 要顯示買的商品、價格、買的數量,而會隨著客戶行為增加,所以非正規化。這裡就是重點。設計上甚至可以直接: 把買的當下的商品圖片、價格、當時庫存、商品描述"通通抄到訂單、付款資料表"。這個就是本文重點。雖然當下覺得: 商品都是顯示那個圖啊,為什麼要抄? 浪費資料庫空間。但哪天遇到: 商品會有外觀變更、升級,卻一定要歸類在同一產品,不能新開產品時,那舊的訂單不就變成顯示新的產品外觀? 這種問題了。所以,抄吧。

所以交易型資料,確定未來不會遇到問題的,才會用JOIN到基本資料去取。否則抄就對了。

那有人會質疑這種設計: 一直浪費資料空間。但是,就算不抄,這種交易型資料本來就隨著經營,資料會越來越龐大,所以一定會設計: 歷史資料移轉。歷史資料移轉的設計必要性遠大於單筆資料的大小了,所以,抄吧。

當然也有人會完全不使用正規化,幾乎避免JOIN可能。這樣會有浪費大量資料庫空間。但這種設計無妨,而是反過來看: 我是不是要取得"即時最新"。這等於是前面的設計的反向,是另一種考量。但是,絕大部分的核心設計,是用前述原則來作,會比較走中間路線。通常使用這種不正規化的設計,會是整個系統的獨立一塊,在前面沒講到。通常用在"報表設計"。透過一整組的報表資料庫(完全反映報表要的欄位),然後另外一組邏輯,把現有的完全正規化/非正規化的資料,轉到這組"絕對沒有正規化"的資料表後,給報表呈現。

很多理論上的資料庫架構設計,往往遇到現實商業系統需求,會造成結構性的毀滅。只能當"懂得資料庫"來學習,應用上還是得跟據經驗走。正如: 我有一個本地端紀錄檔需求,但最多只有記錄100筆時,我會用資料庫還是檔案? 我會用檔案,遠比資料庫快多........<div class='locked'><em>瀏覽完整內容,請先 <a href='member.php?mod=register'>註冊</a> 或 <a href='javascript:;' onclick="lsSubmit()">登入會員</a></em></div>

cmy328 發表於 2018-8-4 02:14 PM

就每天的價格存一個欄位就好 有什麼特別的嗎?

kwj 發表於 2018-8-8 12:05 PM

cmy328 發表於 2018-8-4 02:14 PM static/image/common/back.gif
就每天的價格存一個欄位就好 有什麼特別的嗎?

存一筆紀錄和存一個欄位差很多....如果是 NoSQL 也就算了,RDBMS 的話會搞死人
頁: [1]