【问题标题】:Proper Table naming convention for a many-to-many intersect table多对多相交表的正确表命名约定
【发布时间】:2019-07-30 16:58:06
【问题描述】:

我有一个多对多关系:Client 和 Broker 表(只是一个例子)。显然,每个客户端可以有多个代理,每个代理可以有多个客户端。什么被认为是相交表的正确命名约定......是 ClientBroker......?

【问题讨论】:

  • 虽然这肯定不是惯例,但我喜欢在私人应用程序中将这些东西称为broker2client。这样,我可以直观地快速找到只连接其他表的表。仅从名称 ClientBrokerclient_broker 我不清楚它包含什么。可能是经纪人的客户。

标签: database-design


【解决方案1】:

我更喜欢“Clients_Brokers”(将两个名称复数以表示多对多)。

【讨论】:

  • 我投了赞成票,因为有人投了反对票。我认为这个约定很好,而且经常是必要的。 MVC 框架提供的一些 ORM 库对表有一个命名约定来自动处理关系。我知道至少有 3 个 PHP 框架使用复数名称和下划线分隔这样的多对多数据透视表名称。
  • 这是旧的单数与复数表命名冲突(此处扩展为连接表)。您是否以单数形式命名表 - 例如“客户”,因为每条记录代表一个客户?还是复数,因为表本身包含许多“客户”?这是一个见仁见智的问题,我认为没有理由对此投反对票。
【解决方案2】:

我通常使用两个连接表的名称。

所以,就您而言,ClientBroker。

【讨论】:

  • 按字母顺序排列名称中的表格也很好!一些框架(laravel)使用这种表示法。即BrokerClient 而不是
【解决方案3】:

我更喜欢区分相交表和实际事务表。 所以,我用地图结束它们。所以它将是 Client_Broker_Map 或 ClientBrokerMap。

【讨论】:

    【解决方案4】:

    我经常看到格式“Client_Broker”

    【讨论】:

    • +1:标点符号应该少用,在这种情况下,它有助于区分两侧。
    【解决方案5】:

    一些程序员不喜欢复数表名有几个原因:

    • 它违反了“是”规则,这意味着如果您有一个名为“用户”的表,那么表中的每条记录“都是”用户对象。这遵循面向对象的规则。
    • 模型类通常以其数据来源的表命名。所以如果你有一个 User 模型,那么这个模型所代表的记录就在 User 表中

    如果您可以控制项目的整个数据库和业务层,这很有意义。然而,现在很多框架都有 ORM 库来帮助处理表和关系。这些 ORM 库通常具有应遵循的命名语法,以便让 ORM 库完成大部分繁重的工作。

    例如,我使用用于 PHP 的 Kohana MVC 框架,它提供了一个 ORM 库。 ORM 建议使用复数形式的表名,使用所有小写的名称,并使用下划线表示多对多的表名。因此,对于您的示例,您将拥有以下表:clients、brokers 和 brokers_clients(ORM 建议按字母顺序排列多对多表的表名)。在为这些表创建模型(扩展 ORM 模型)时,您使用表名的奇异值,因此客户端的模型将是 Client。 ORM 处理复数转换。 Kohana 的 ORM 还使用了一个变形库,因此可以正确处理不寻常的复数值。例如,名为“categories”的表可以使用模型名称“Category”。最后,如果你有一个已经实现的 db 结构但是想使用 ORM 库,你可以覆盖默认的 ORM 表命名语法,并给它你要使用的表名。

    【讨论】:

      【解决方案6】:

      我正处于一个项目的中间,我正在使用 DESCRIBE 获取表和字段名称。我会使用 Client_x_Broker,这样我就可以轻松地找到一个表并通过使用 _x_ 作为标准来获取字段,这是一个在代码或数据集中自然不会出现的字符串,无论如何也不会在我的,并且很容易strp out 查找单个表的名称。此外,只要我保持一致,我就可以从表名中获得很多信息,包括主键名。对不起,a,迟到了,b,继续。 :)

      【讨论】:

      • 我可能会选择这个。考虑表名和模型名。 ClientsBrokers 型号?没那么糟糕,大概吧。当你实例化它时? clients_brokers?复数形式是什么? ClientBrokerMap 稍微好一点。但如果你问我,更好的是ClientBrokerRelationship。而ClientXBroker 是一个很好的合同方式。
      • @x-yuri 为什么您的数据透视表需要模型?大概你会有一个 Client 模型和一个 Broker 模型,但我看不出有 ClientsBrokers 模型的意义。
      • @Mike 您会将有关关系的数据放在哪里?看看来自Django docs的例子
      • @x-yuri 啊,我明白你的意思了。我对学习 MVC 和目前学习 Laravel 比较陌生。 Laravel 处理数据透视表的方式略有不同 (laravel.com/docs/5.6/eloquent-relationships#many-to-many)。本质上,在一个模型上,您定义与另一个模型的hasMany 关系,而在另一个模型上,您定义与第一个模型的belongsToMany 关系。据我所知,没有必要创建一个实际的数据透视表模型。
      • 首先,你在两端使用belongsToManyhasMany是一对多的关系。然后,don't have to 在不需要时在 Django 中定义中间模型。顺便说一句,您只在一端指定关系。 “哪个模型具有 ManyToManyField 并不重要,但您应该只将它放在其中一个模型中,而不是两个模型中。”
      【解决方案7】:

      对于 Hibernate 用户,根据日志消息和分析生成的查询,通过反复试验发现了未记录的规则:

      形式化这张图片,你需要使用一个名为:table1_table2 的链接表,并在链接表中使用 id,例如:table1_table1Id 和 table2_table2Id

      通过这样做,Hibernate 无需进一步解释即可了解发生了什么并提供@JoinTable 信息。

      @Data
      @Entity
      @Table(name="course")
      public class Course {
      
          @Id
          @GeneratedValue(strategy= GenerationType.AUTO, generator="native")
          @GenericGenerator(name = "native", strategy = "native")
          private Long courseId;
      
          @Column(name="name")
          private String name;
      }
      
      @Data
      @Entity
      @Table(name="student")
      public class Student {
      
          @Id
          @GeneratedValue(strategy= GenerationType.AUTO, generator="native")
          @GenericGenerator(name = "native", strategy = "native")
          private Long studentId;
      
          @Column(name="name")
          private String name;
      
          @Column(name="class")
          private String className;
      
          @ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE})
          private List<Course> course;
      }
      

      如果你坚持这个映射,所有的 JPQL 查询都能顺利运行,并按预期生成正确的带有外连接的 SQL 查询...注意,course 没有 -s 在结束!如果您想要课程s,您应该将连接表中的字段名称更改为 table2s_table2Id,并将表本身更改为 table2s

      P.S. 我在 JPA 和 Hibernate 文档(仅在单个 example)中都没有找到任何直接提及此约定的内容,并且它可能会在未来的版本中更改,使用休眠 5.2/5.3。但是它提示了如何命名连接表和其中的字段。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2016-12-28
        • 2013-06-12
        • 2016-09-21
        • 1970-01-01
        • 2014-08-07
        • 1970-01-01
        • 2019-12-17
        相关资源
        最近更新 更多