当前位置：首页 → 问答吧 → 关於资料库内"多对一"的资料表设计

关於资料库内"多对一"的资料表设计

时间：2014-03-19

来源：互联网

如果有个购物交易系统
有以下3个Table:

Table 1 : Member
会员资料

Table 2 : Company
公司资料

Table 3 : Transaction
此为交易的记录, 但由於会员(Member)及公司(Company)皆会作出交易,
则这个"交易者"栏应如何设计,

例如, 根本不可以foreign key去Member这个table,
因为Company都会作出交易

作者: Richards 发布时间: 2014-03-19

咁 login 嗰嘢又点呀?

分别 check member 同 company 呢两个 tables?

引用:原帖由 Richards 於 2014-3-5 12:37 发表
如果有个购物交易系统
有以下3个Table:

Table 1 : Member
会员资料

Table 2 : Company
公司资料

Table 3 : Transaction
此为交易的记录, 但由於会员(Member)及公司(Company)皆会作出交易,
则这个"交易 ...

作者: a8d7e8 发布时间: 2014-03-19

用trigger或front-end去做validation啦

作者: skww 发布时间: 2014-03-19

引用:原帖由 a8d7e8 於 2014-3-5 12:49 PM 发表
咁 login 嗰嘢又点呀?

分别 check member 同 company 呢两个 tables?

仍未谂Login这部份

作者: Richards 发布时间: 2014-03-19

引用:原帖由 skww 於 2014-3-5 02:18 PM 发表
用trigger或front-end去做validation啦

谢谢师兄,
其实是否这类情况, 不可在Database层面做功夫?
即使不作Validation,
如果Member个PK(主键)是一个Integer
而Company个PK是一个Char,
同样不能解决, 通常大家会怎面对这些问题呢?

[ 本帖最后由 Richards 於 2014-3-5 03:09 PM 编辑 ]

作者: Richards 发布时间: 2014-03-19

从 design 去解决......

根据 member 同 company 间既关系, company 是否 member 之一? 若否, 是否可抽出一个 superclass?

例如, user.

member 又系 user, company 又系 user.

引用:原帖由 Richards 於 2014-3-5 14:30 发表

谢谢师兄,
其实是否这类情况, 不可在Database层面做功夫?
即使不作Validation,
如果Member个PK(主键)是一个Integer
而Company个PK是一个Char,
同样不能解决, 通常大家会怎面对这些问题呢?

作者: a8d7e8 发布时间: 2014-03-19

引用:原帖由 a8d7e8 於 2014-3-5 03:19 PM 发表
从 design 去解决......

根据 member 同 company 间既关系, company 是否 member 之一? 若否, 是否可抽出一个 superclass?

例如, user.

member 又系 user, company 又系 user.

有道理,

但另一方面, 这个user 和member及company的关系,
是否会变成user --1:N--member 及 user --1:N--company,
因为应是user及company内有一个栏位指向user,

作者: Richards 发布时间: 2014-03-19

其实再简单直接在 member 建立一个公司用的户口就可.

完全不需要理会 company 同 transaction 关系.

引用:原帖由 Richards 於 2014-3-5 16:04 发表

有道理,

但另一方面, 这个user 和member及company的关系,
是否会变成user --1:N--member 及 user --1:N--company,
因为应是user及company内有一个栏位指向user,

作者: a8d7e8 发布时间: 2014-03-19

引用:原帖由 a8d7e8 於 2014-3-5 04:56 PM 发表
其实再简单直接在 member 建立一个公司用的户口就可.

完全不需要理会 company 同 transaction 关系.

师兄意思是否:
如果member有100人, company 有26间,
则member有126个记录,

但这样, member内的公司,
关於"人"属性的所有field是否都会为NULL?
若是的话, 这种设计会否不太好

作者: Richards 发布时间: 2014-03-19

两table归一, member有个column叫type, l for individual, C for company.
取消company table.

如果两类分别太大, (可能一半栏位空置), 另开子table.

作者: Pseudo 发布时间: 2014-03-19

复制内容到剪贴板代码:Person
^
|
1:1
|
v
Member <--- 1:N ---> Transaction
^
|
1:1
|
v
Company

作者: fitcat07 发布时间: 2014-03-19

引用:原帖由 Pseudo 於 2014-3-5 06:04 PM 发表
两table归一, member有个column叫type, l for individual, C for company.
取消company table.

如果两类分别太大, (可能一半栏位空置), 另开子table.

+1,
this is a typical usage of "Single Table Inheritance",
Single Table Inheritance 适合 few subtypes and few subtype-speciﬁc attributes,

http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html

IMHO, transaction table 应该改名Orders , 因为完全同 transaction无关

[ 本帖最后由 form5 於 2014-3-5 09:55 PM 编辑 ]

作者: form5 发布时间: 2014-03-19

引用:原帖由 fitcat07 於 2014-3-5 06:40 PM 发表
Person
^
|
1:1
|
v
Member Transaction
^
|
1:1
|
v
Company

参考了大家的意见后, 我认为这应算是解决方案,
但算我打拦沙盆问都督, 用什么方法保证Member 和 Company等是1:1,
因Company内的一个field(其PK)是foreign to Member的主键,
则可以看出, 可以一笔Member在Company内有两笔资料,
一般的做法如何呢?

作者: Richards 发布时间: 2014-03-19

引用:原帖由 form5 於 2014-3-5 09:53 PM 发表

+1,
this is a typical usage of "Single Table Inheritance",
Single Table Inheritance 适合 few subtypes and few subtype-speciﬁc attributes,

http://www.martinfowler.com/eaaCatalog/singleT ...

谢谢师兄!!

你列出的参考很有参考价值, 学到嘢

作者: Richards 发布时间: 2014-03-19

引用:原帖由 Richards 於 2014-3-5 05:37 PM 发表

师兄意思是否:
如果member有100人, company 有26间,
则member有126个记录,

但这样, member内的公司,
关於"人"属性的所有field是否都会为NULL?
若是的话, 这种设计会否不太好

只要有多一个 field 能分辨到特别的 field 是否有用就不必考虑用 null 的问题。
例如有一个 field 能判别 member 的“type”是“个人”或是“公司”，那么当是个人时，“商业登记号码”是什么数值也无所谓，因为根本不适用。
query 时根本就不用考虑 null 的问题了。
不过 query 时当然要考虑 member 的“type”。
使用这个方法的话，可以好容易的设计 index 。

作者: xianrenb 发布时间: 2014-03-19

引用:原帖由 Richards 於 2014-3-6 12:55 AM 发表
用什么方法保证Member 和 Company等是1:1 ...

唔好理 Member 同 Company，又或你宜家嘅情况。一般嚟讲，你用乜嘢方法去保证两个 table 关系系 1:1？

作者: fitcat07 发布时间: 2014-03-19

引用:原帖由 xianrenb 於 2014-3-6 08:57 AM 发表

只要有多一个 field 能分辨到特别的 field 是否有用就不必考虑用 null 的问题。
例如有一个 field 能判别 member 的“type”是“个人”或是“公司”，那么当是个人时，“商业登记号码”是什么数值也无所谓，因为根 ...

明白,

但若"人"是有很多属性, 但Company有很多笔记录,
虽然如师兄所讲, query时每次都用这个"type"作为where的条件便没有问题,
但这个设计, 个Table是否会浪费很多空间, 即很多笔记录的很多field为null,

以前读书时讲normalization, 是否就是不想见到呢种情况呢?

作者: Richards 发布时间: 2014-03-19

你做紧嘢喇? 仲以为你问功课添.

又会唔识都俾你 design 既?

引用:原帖由 Richards 於 2014-3-6 10:40 发表

明白,

但若"人"是有很多属性, 但Company有很多笔记录,
虽然如师兄所讲, query时每次都用这个"type"作为where的条件便没有问题,
但这个设计, 个Table是否会浪费很多空间, 即很多笔记录的很多fiel ...

作者: a8d7e8 发布时间: 2014-03-19

引用:原帖由 Richards 於 2014-3-6 10:40 AM 发表

明白,

如果是用传统 RDBMS 的话，我觉得是没有办法，只能以浪费空间来换取效能。
因为用任何其他方法的话，相信最终都要利用 join ，而 cross-table index 这个功能我估大部份 relational database 都未有。
所以较理想解决的方法，我估一是用一个 table 记载所有 data ，一是用 ORDBMS （如 PostgreSQL ）。
使用 ORDBMS 就有 inheritance 功能可以直接用。
由 database layer 处理肯定比用 application layer 处理容易得多。

作者: xianrenb 发布时间: 2014-03-19

nosql , big table la.

作者: private4u 发布时间: 2014-03-19

关於资料库内"多对一"的资料表设计

热门阅读

热门下载