代码之家  ›  专栏  ›  技术社区  ›  Paul Sasik

数据库模式中的“快捷方式”列有什么借口吗?

  •  0
  • Paul Sasik  · 技术社区  · 15 年前

    昨天,我注意到详细信息表中有一个外键列直接链接到客户表。这个细节表只是客户头表删除的一个连接,它已经是客户的正确外键和细节,请跟我说。

    [Cust] ---< [Header] ---< [Detail]
      |                          V
      |________ wtf? ____________|
    

    ASCII数据库建模键 :

                              V
     ---< = 1 to many,  and  _| also = 1 to many
    

    当我在这个问题上按下表的设计者时,他为这个问题辩护,解释说他将使用这个列保存一个连接调用…

    在IMO中,这就节省了一个输入缓慢、懒惰的SQL编写器,不必以模式非规范化的代价加入一个额外的表。(本例直接失败的是哪种正常形式?)

    即使使用这样的概念节省了十几个连接,是不是 曾经 值得的?

    6 回复  |  直到 15 年前
        1
  •  1
  •   Andrew    15 年前

    这是一个经典的答案“它取决于”-一个大小不适合所有人,你所看到的是一个纯粹的偶然方法与一个务实的方法之间的永恒平衡。任何一个方向太远都会产生不好的结果,所以有时你会牺牲偶然性的正确性来让某些东西工作得很好。

    在不知道工作负载、查询数、优化结果将/不会使用联接的频率等情况下,无法确定这种情况是过早优化还是有效优化。

        2
  •  2
  •   Mitch Wheat    15 年前

    是否存在无法通过添加适当索引来解决的实际性能问题?

    如果不是这样,那么在某些情况下引入这样的“循环”会导致数据冲突,我将避免这种情况。

        3
  •  1
  •   chaos    15 年前

    对。消除连接可能会影响性能;直接返回运行速度足够快的用户界面以使该界面可用的查询是一个优于设计纯度的考虑因素。

    尽管对于在一个标准化良好的核心模式和一组支持UI的汇总表之间维护一种分区还有一些话要说。

        4
  •  1
  •   OMG Ponies    15 年前

    即使使用这样的概念节省了十几个连接,它是否值得?

    数据库设计器/数据建模器的正确答案是 CUSTOMER 记录可以与 DETAIL 无支持记录 HEADER 根据业务规则记录。

    为了添加外键会破坏数据模型,从而导致数据错误。如果只有一个 细节 与关联的记录 顾客 ,那么我希望在 页眉 表-这是corrollary/xref/lookup表的要点,允许0+个支持记录。它也保持了疑问的一致性——这些都不是“今晚月亮在哪座房子?”导致大量查询的失败…

        5
  •  0
  •   HLGEM    15 年前

    不知道您的表结构,我将指出向多个子表添加客户ID是一种常见的非规范化。从你所说的来看,他把它做成了一个外键,所以这样做没有风险,而且有很多潜在的性能优势。

    只要标题表还有一个外键,我就不会看到设计上的问题。

    有经验的数据库人员知道将针对表编写的查询类型,可以在设计时看到其中一些非规范化。如果我有多个客户,我可能希望能够按客户查询明细表,而不必在许多情况下浏览标题表。当然,这将取决于在查询的头表中是否有我想要的任何信息。在这里,我们可以根据特定查询的最佳选择进行选择,并且所有约束都已就位以防止数据完整性问题。我们只需要一点额外的磁盘空间。

        6
  •  0
  •   Erwin Smout    15 年前

    “数据库设计器/数据建模器的正确答案是,根据业务规则,在某些情况下,客户记录可能与详细记录相关,但不支持标题记录。”

    很明显,这两种关系都是一对多的,因此不支持头记录的详细记录是不可能的。

    但可能的是,细节中的某些内容与另一个客户相关,而不是在遵循标题/客户“路径”时找到的客户。尽管可能不太可能,但只有定义模式的人才能回答这个问题。