毫无疑问，方案二更贴合数据库设计的最佳实践，下面从几个核心维度拆解原因：

• 遵循数据库规范化原则
  方案一的问题在于把仅属于部分车辆的属性硬塞进主表，会产生大量的NULL值，这直接违反了第三范式（3NF）的核心要求——每个属性应该只对应实体的一个核心特征，且完全依赖主键。展示车辆根本不需要Price和PriceNotes，把这些字段放在Car表里，不仅浪费存储，还会让表的语义变得模糊：到底Car表是记录车辆基础信息，还是同时管售卖信息？
  方案二则通过拆分出SaleInfo表，让每个表各司其职：Car表专注存储车辆本身的通用属性，SaleInfo表只记录和售卖/拍卖相关的信息，数据结构清晰，完全符合规范化的设计思路。

• 保障数据完整性，减少无效数据
  用方案二的话，我们可以给SaleInfo表的CarID设置外键关联Car.ID，还能通过CHECK约束（或触发器，视数据库类型而定）限制它只能关联IsDisplayOnly = false的车辆。而且如果Price是售卖车辆的必填项，直接给SaleInfo的Price字段设非空约束就行，从底层避免了“售卖车辆却没有价格”的无效数据。
  但方案一做不到这类强约束：总不能给Price设非空吧？毕竟展示车辆的Price必须是NULL，这就导致无法强制售卖车辆必须填写价格，很容易出现数据不一致的情况。

• 扩展性更强，适配业务变化
  假设以后业务扩展，比如要给拍卖车辆加AuctionStartTime、ReservePrice、BidCount这类专属字段，方案二只需要在SaleInfo表里新增字段就行，完全不会影响Car表的结构和展示车辆的数据。
  但方案一的话，每次新增售卖相关字段都要修改Car表，还要允许展示车辆的这些字段为NULL，久而久之Car表会变得越来越臃肿，维护成本直线上升。

• 查询效率更优
  当查询展示车辆时，方案一的Car表因为带了额外的售卖字段，数据量更大，查询时需要扫描更多的数据页。而方案二查询展示车辆只需要从Car表取数据，不用加载那些无关的售卖字段，速度更快。
  另外，统计售卖车辆的价格信息时，直接查SaleInfo表就可以，不用过滤大量的NULL值，效率也更高。

当然，方案一也不是完全没适用场景——如果你的业务里几乎所有车辆都是售卖状态，只有极少数是展示的，那少量NULL值的影响可以忽略。但从长期业务发展和数据库结构的健壮性来看，方案二的设计显然更稳妥。

内容的提问来源于stack exchange，提问作者TuanDT