一个网上商店数据库的设计与实现的疑问。
现在有四张表：订单表、用户表、收货人信息表、评论表。其中一个订单对应一个用户；一个用户可以有多个订单；用户有多个收货信息（可以帮其他人下单、收货地址不同就产生多个常用收货信息记录）；一个订单对应一个评论；各表定义如下:Order(OrderId,UserId,ReceiverId,……)、User(UserId,UserName,……)、Receiver(ReceiverId,UserId,Address,Tel,……)、Comment(CommentId,UserId,OrderId,Content,……)等等。请问在订单Order中记录UserId和评论表Comment中记录UserId是否合理。因为有了ReceiverId就可以确定了User，而有了OrdreId也可以确定User了。我设计的思路是为了避免多表的链接。请问在设计原则和理论以及可操作性上有什么优缺点。另外我想在程序中是分步实现上述表的操作的。有什么好的设计方案？长了点，希望看得明白

------解决方案--------------------
假设你的“评论”就是按照你说的那种意思，那么评论就和应该放到订单中，而不是独立出来。但是有时候我们的一个子系统跟其它系统是分别上线的，那么虽然它们有“一对一”关系，也许为了维护不同子系统的独立性（可装配性）而把评论独立出来，保存OrderId，也是可以的。何况我认为一个订单完全应该有多个评论，因为这是随便想一想就能发现的用户需求。

实际上真正的技术不是体现在你第一次搞什么“完美的”设计，真正的技术是体现在重构过程中，这要比你说的“分布实现表的操作”更要有技术。但是很多人（很多公司）只想忽悠个1.0版本，以后再去继续研发之前的产品就不知道要等到多少年之后再说了。这样的公司很难有真的市场销售的产品。

回过头来谈你的描述：“我设计的思路是为了避免多表的链接。请问在设计原则和理论以及可操作性上有什么优缺点”，其实这是“不太入流”的说法，会存在这种说法而且在有些技术经验交流会上还会有人极力证明其“合理”。但是一般人来说，你的麻烦很快就来了，因为你冗余了，于是你需要为了维护而花费大代价、多浪费做好几倍的代码运行时间。

有没有可能使用冗余快表？当然有！但是不是在基本数据库结构上搞这类东西。例如你可以在数据缓存上努力，或者定期地用系统任务进程去创建统计报表并预存在数据库中（于是查询时去访问统计报表而不是原始数据）。也就是说是从业务范畴上就去定义新的数据表，而不是胡乱冗余基本数据表。