帮我看看这个database design

lmb

Design 1

Purchase
-------------------
purchase_id | PO_no | date | ref_no | supplier_id


Sale
---------------
sale_id | invoice_no | date | ref_no | customer_id


Transaction
-------------
transaction_id | type (sale or purchase) | id ( sale or purchase id) | item_id | quantity | price



Design2

Purchase
-------------------
purchase_id | PO_no | date | ref_no | supplier_id


Purchase_detail
---------------------
purchase_detail_id | purchase_id | item_id | quantity | price


Sale
---------------
sale_id | invoice_no | date | ref_no | customer_id


Sale_detail
---------------------
sale_detail_id | sale_id | item_id | quantity | price


Transaction
----------------------
transaction_id | type (sale or purchase) | type_id (sale_id or purchase_id)


Design 1
我想知道的是，如果我这样design我的database,
我把全部的sale和purchase的资料都放在transaction这个table,
这样就会方便我做report和check stock。。
我们target一天会有整千个sale/purchase
你们有什么好的建议吗？
我这个方法有什么好处和坏处？


Design 2
如果design 2這個方法呢？

是不是比較好？

hair salon, jantzen salon, beauty salon

[ 本帖最后由 lmb 于 27-11-2005 11:04 AM 编辑 ]

flashang

如果資料會太多, 可以考慮把 transaction 分成每一個月一個 table
transaction012005, 022005, 等等,
但是在存取資料時需要費些功夫.

[ 本帖最后由 flashang 于 26-11-2005 01:41 PM 编辑 ]

我认为你可以把所有的purchase and sale information include in the transaction table,like ref_no,item,qty,price and etc....

if like that you system only access 1 table rather than access both 3 table, it will make system sql time more faster

o1j2m3

哈哈~ 不错不错

小系统用1
大系统用2

大系统用1准备撞墙
小系统用2工作多一点点

1后来可以慢慢变2

~很久没疯疯的冬瓜~留言。。

o1j2m3

原帖由 flashang 于 26-11-2005 01:37 PM 发表
如果資料會太多, 可以考慮把 transaction 分成每一個月一個 table
transaction012005, 022005, 等等,
但是在存取資料時需要費些功夫.

哈哈，很好很好。。。是很费工夫，那个功夫比你买伺服器还贵

~疯人疯语~别见怪~

o1j2m3

原帖由 gaobeigaomu 于 14-12-2005 09:19 AM 发表
我认为你可以把所有的purchase and sale information include in the transaction table,like ref_no,item,qty,price and etc....

if like that you system only access 1 table rather than access both 3 ta ...

速度可以那么算，哈哈，你可以变百万富翁了。

不同资料库有不同算法，不同分量的资料也有不同算法，不同程式写法也有不同算法~你是用哪一个算法？


~细细的雨~在噼啪噼啪地响。。。。。

flashang

原帖由 o1j2m3 于 24-12-2005 04:08 PM 发表

哈哈，很好很好。。。是很费工夫，那个功夫比你买伺服器还贵

~疯人疯语~别见怪~

目前有一個顧客每一天的 transaction 大約有 1000 records,
transaction details 大約有 5000 - 6000 records,
一個月下來就有 200'000 records

如果用 transaction, transactiondetails 的方法, 幾乎每機個月 database server 都會當機,
而解決的方法就是把 export 去其他的 database mmyyyy, 並且把 working database empty 掉,
而 report 就需要去不同的 database mmyyyy 捉 data

我想问下。。。。如果用1，然后设计一个Transaction的View， 例如ViewForReport和ViewForCheckingStock。

然后Report和Check Stock就只是读那个View就可以了，如何？

[ 本帖最后由 不恥下問學IT 于 25-12-2005 01:58 PM 编辑 ]

o1j2m3

原帖由 flashang 于 24-12-2005 04:35 PM 发表


目前有一個顧客每一天的 transaction 大約有 1000 records,
transaction details 大約有 5000 - 6000 records,
一個月下來就有 200'000 records

如果用 transaction, transactiondetails 的方法, 幾乎每 ...

这个嘛～也未必需要一个桌子一个桌子抓～
总之。。。haha，资料库ma ...
保持神秘啦

o1j2m3

原帖由 不恥下問學IT 于 25-12-2005 01:57 PM 发表
我想问下。。。。如果用1，然后设计一个Transaction的View， 例如ViewForReport和ViewForCheckingStock。

然后Report和Check Stock就只是读那个View就可以了，如何？

如果有parameter，可以～
不然，看情况罗～

^_^

flashang

原帖由 o1j2m3 于 25-12-2005 09:23 PM 发表


这个嘛～也未必需要一个桌子一个桌子抓～
总之。。。haha，资料库ma ...
保持神秘啦

戲法人人會變，巧妙各有不同.

不是所有的問題都可以用同一種方法來解決,
你的方法也未必適合我的情況 / 限制

有些時候還是要根據顧客的情況來改變方法 ...

[ 本帖最后由 flashang 于 26-12-2005 01:51 PM 编辑 ]

o1j2m3

玩过2GB以上的资料库的～我那方法多数没有问题的～

抱歉抱歉～别生气～生气会变老的～

原帖由 o1j2m3 于 25-12-2005 09:25 PM 发表


如果有parameter，可以～
不然，看情况罗～

^_^

Parameter？ 什麽Parameter？ PrimaryKey 還是RowID？