佳礼资讯网

 找回密码
 注册

ADVERTISEMENT

查看: 1720|回复: 4

ERP 的 DB 问题?

[复制链接]
发表于 8-10-2014 04:08 PM | 显示全部楼层 |阅读模式
如果一个ERP系统

使用SQL server。 为了不那么多table, 把一个invoice分去两个
table: 1.header 2.footer。

就是header里面有 invoice no, date, 。。。
footer就是 invoice no,item, sortorder,quantity。。。。

这种方式,data redundant, 只是容易写SQL


Opencart mysql 那种方式就有很多的mapping table。

要系统跑快不要分那么多table,但backup就很大的文件。

如果你有这方面的经验,可以分享一下吗?感激不尽。








回复

使用道具 举报


ADVERTISEMENT

发表于 8-10-2014 05:17 PM | 显示全部楼层
讲真。。。不懂你在讲什么

多 tables 就可以 normalization, 要 join table 才能拿到你要的资料,比较适合 relational database
少 tables 就不用 normalization,不用 join table,可以快点,nosql 就是做这些

评分

参与人数 1人气 +2 收起 理由
rcyaw2 + 2 我很赞同

查看全部评分

回复

使用道具 举报

发表于 17-10-2014 09:28 PM | 显示全部楼层
使用SQL server。 为了不那么多table, 把一个invoice分去两个
table: 1.header 2.footer


我覺得 1號改成 invoice, 2號改成 itemize 會比較確切表達你的意思吧?

就是header里面有 invoice no, date, 。。。
footer就是 invoice no,item, sortorder,quantity。。。。

这种方式,data redundant, 只是容易写SQL


如果你的意思是
方案1, 只有一個 table , 裡面有 invoice no, date,item, sortorder,quantity
這樣就只有一個 table, 不用join, 寫 query 容易, 但是資料會redundent

方案2, 拆分成兩個 table, 分別是 invoice 跟 invoice_itemize
invoice : id, invoice no, date
invoice_itemize: id, invoice_id(fk), item, sortorder, quantity

在DBMS的世界裡面, 的確, 不拆table 不 Normalize是最速方法,
但是你要考量這幾點:

1) 到底是 join 消耗的時間比較浪費, 還是浪費那幾KB的空間比較浪費?
原古時候(1980+), 那時候HD的空間應該以MB來計算的, 但是那時16bit 的CPU 以計算文字來說已經非常快速了. 所以他們一定要節省空間, 浪費一點運算時間並不是問題(trade off)

到了現在, 你可能認為那幾KB不算甚麼, 但是如果你的交易量是以 Million來計算, 你損失的空間就很可觀了
但是你是單一invoice的 join. 也就是(1invoice * 10~20 item) 充其量浪費的運算時間大概是 0.001~0.002秒.

我想這個trade off 很簡單明瞭吧?

實際上我不惜把整個架構分拆成6~7個table, join 起來的時候如果語法寫得好, 並且有妥善建立 fk 跟 index, 運算速度還是很可觀的, 反倒是你把6~7個table 只用一個table 紀錄, 損失的空間真的很浪費.

2)寫program的邏輯
今天如果我要 print out 這個 invoice, 一定就是讀invoice 裡的資料後, 在根據invoice 的id 取出對應的itemize
如果你只有一個table, 那我問你, 你要怎樣讀取 invoice 共同的資料(invoice no, date)? group by? limit? 任何的select 語法以 primary key 去選取 (ex: select * from invoice where id=1)  肯定比 (select invoice id, date from invoice where invoice_no =1  limit 1) 來得快.

總結

  1.   長痛不如短痛
  2.   你設計的時候辛苦normalize, 好過你以後要因需求變更修改DB架構來的好
复制代码

评分

参与人数 1人气 +5 收起 理由
rcyaw2 + 5 谢谢分享

查看全部评分

回复

使用道具 举报

 楼主| 发表于 25-10-2014 06:20 AM | 显示全部楼层
非常谢谢大大。 我看到就只是两个table。 1 个invoice 或则 SO, PO, 有header
part 就是 invoice_NO (只是一个的data), footer(itemize)可以有无限个。 当然还会有 product table,user table, customer table。


可以说那个DB的data很多,有1GB那么大。我在想有什么方法可以节省space?

回复

使用道具 举报

发表于 25-10-2014 06:01 PM | 显示全部楼层
rcyaw2 发表于 25-10-2014 06:20 AM
非常谢谢大大。 我看到就只是两个table。 1 个invoice 或则 SO, PO, 有header
part 就是 invoice_NO (只 ...

如果是使用人家的系統(買/免費), 對於空間不足, 直接購買新的HD會是比較簡單的處理方法,
系統就不要儘量不要去更動.

如果是備份造成的空間不足, 例如1GB的DB 每天Backup, 一個月下來需要30G,
那更簡單, 較舊的備份資料直接壓縮成tar / rar就好, 我的經驗是, 2GB的資料壓縮到來可以到400M

當然還有更古老的方法, 請參考這個:
60 歲的磁帶或許仍是資料儲存最佳選擇?

但是如果你是因為你的系統是 host 在人家的服務裡面, 而Service provider 又很吝嗇只給你2GB的空間
上面就有提到所謂的"冷資料", 就是把很舊的PO, SO裡面超過2年前的舊資料, 備份後再刪除他.



回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

 

ADVERTISEMENT



ADVERTISEMENT



ADVERTISEMENT

ADVERTISEMENT


版权所有 © 1996-2023 Cari Internet Sdn Bhd (483575-W)|IPSERVERONE 提供云主机|广告刊登|关于我们|私隐权|免控|投诉|联络|脸书|佳礼资讯网

GMT+8, 25-8-2025 05:39 AM , Processed in 0.104080 second(s), 29 queries , Gzip On.

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表