请问这样的数据库结构设计合理吗？？
0
悬赏园豆：50
[已解决问题]
解决于 2010-10-26 15:48
需求是这样的，拿淘宝来举例：
淘宝平台T，上面有2个商店A、B，共用平台T的会员，又有各自的商品、会员积分
我计划数据库这样设计：
用schema来分割不同的商店，即会存在这样3个表
T.MemberTable, A.MemberPointTable, B.MemberPointTable
T、A、B是不同的schema，并且数据表按不同schema保存在不同的物理文件。
T.MemberTable与A、B的MemberPointTable都有关联，如果某会员在A店获得了积分，那么在A.MemberPointTable插入记录就可以了。
请问这样数据库设计合理不，我是希望尽量保证各商店的相对独立性
还有，是否需要每个schema有一个对应的sql server用户？还是统一用一个，例如sa。
另外，求给扔点类似这种C2C的项目参考，codeplex搜C2C竟然没有……
最佳答案
0
英语不好,MemberPointTable 就是会员积分表吧!
A.MemberPointTable, B.MemberPointTable就不用区分了吧,合在一张表 MemberPointTable 中.
关系数据库,你尽量还是按照关系范式来设计你的架构.
你需要一个 Store(商店) Member(会员) MemberPoint(会员积分) MemberPointDetails(会员积分明细) Product(商品)
Store-Member(商店与会员的映射表) Store-Product(商店与商品的映射表)
这样就利于 Store ,Member,Product的扩展。
收获园豆：40
大大不要笑话我……我英文也烂到家，表名随便起的……
其实我主要是想问这种希望独立安全性的需求场景，是否有使用schema的比要，用schema来物理分割不同商家的表是否可行。举个例子，A商店的产品只会保存在A.Product表，物理文件可能是ap.mdf，如果这个文件坏了，那么只是A商店的产品没了，不会影响B商店、C商店...
@wdwwtzy:我觉得没必要，如果你的mdf都放在同一台机器上，文件损坏可不会刚好落在某个文件上，你应该对你的整个库做冷备和热备，这都有现成的实施方案和工具。当你的数据库有问题后，应用可以方便的切换到备份上。
其他回答(1)
0
共用平台T的会员 应该和商店A、B 没有关系吧，积分只是和会员有关系吧，和A,B也没有任何关系，用一张表存会员的积分就可以了，
你只需要：
MemberTable（会员表）,MemberPointTable（积分表），Product(商品表)
收获园豆：10
同1楼……
