首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >什么是命名链接表的好的经验法则?

什么是命名链接表的好的经验法则?
EN

Software Engineering用户
提问于 2013-06-06 15:35:10
回答 3查看 233关注 0票数 4

就像publication表可能通过subscriptionsperson表相关联,或者company表可能通过employeeperson表相关联一样,我想知道是否有一种描述性方法将company表与company_type表相关联。

下面是一些相关表的粗略(和简化)示例。

公司:

  • id_

company_type:

  • \x类型说明

{所需名称}:

  • |id|company_id|type|

而且,我意识到并非所有的关系都可以像subscriptionsemployee那样简洁地命名,所以如果这里是这样的话,有什么好的经验法则可以避免与company_types之类的东西发生近名冲突呢?

其他详情:

就我们目前的情况而言,公司类型有些复杂。该行业有多个供应渠道和多个客户渠道,因此,虽然“供应商”是一个有效的company_type,一个供应商也可以“独立”,“授权”,或“专利”……或者三者的任何混合。

客户类型是非常相似的多方面的,为了进一步解决这个问题,单个公司可以同时拥有一些供应商和客户类型。

EN

回答 3

Software Engineering用户

发布于 2013-06-06 15:58:07

你似乎在公司和company_type之间有着一对多的关系。一家公司可以是多种类型的?也许您可以给给定公司的类型集一个名称,“概要文件”,“分类”。

company_profile或company_classification

或者,你也可以描述这种关系,例如:

company_link_company_type

票数 2
EN

Software Engineering用户

发布于 2013-06-06 16:18:20

当您对链接表没有明确的命名约定时,可能会出现此类问题。但是对于一定大小的数据库模式,有这样的约定确实有帮助,特别是当您有多个人处理该模式时。此外,您还应该有其他一些更通用的命名约定,比如何时使用单数和复数,如何命名主键和外键等等。

对于链接表,这可能会产生类似@Joppe建议的“技术”名称,或者产生像company_company_type或company_to_company_type这样的名称。但是,当你在你的组织内传达这个惯例时,这不应该成为很大的问题。一旦你做了决定,就一定要遵守那个约定。

票数 1
EN

Software Engineering用户

发布于 2013-06-06 18:25:36

贴标签很容易。命名东西是很难的。很多时候,我们依靠相邻的术语或默默无闻的假设来提供技术上的区别,而不提供明确、明确的区分。引用一段无关上下文的话很好地说明了这一点:

下面这张便条在伦敦很有趣:“亲爱的先生,为什么从上星期六起我就没有得到你的爱的证据?”我一直焦急地等着。签名夏洛特·伯里。但当读者得知夏洛特·伯里夫人有一本名为“爱在新闻界”的小说,而这张纸条是写给她的打印机时,这种乐趣就消失了。

-卡兹利特·阿文,“文学和美术奇闻百科全书”,1853年

文章的来源来自无用衣橱

重言式

在各种形式和应用中,重言式指的是多余的用法:红血、种类、类别。没有通过使用特定的描述符来进行澄清。

分类学

分类法是一种包含一组描述事物的结构化规则的方案。这一方案可能是面向关系(亲子关系,专业化-泛化,继承-组合),但它可以组织起来,围绕其他识别策略。规则集中越早,规则就越不具体,而后面的规则提供了区别,否则就会有细微的区别。它描述了一个分类过程。模型可能是分类法的体现。

分类化

这是为某物的整体贴上标签以便计数或测量的过程。该主题满足一定程度的相似性,并缺乏任何丧失资格的特点,我们可以称之为同样的。

特征化

这些是事物的个别特征或特征。这可能包括人格或行为的品质。或者它们可能是物理属性。

为了解决眼前的问题,引用Bob叔叔的“干净代码”:

变量、函数或类的名称应该回答所有的大问题。它应该告诉你为什么它存在,它做什么,以及它是如何使用的。如果名称需要注释,则名称不会显示其意图。

Martin,Robert C. (2008-08-01)。清洁代码:敏捷软件工艺手册 (第18页)。皮尔森教育(美国)。Kindle版。

我们面前的是一个心理地图 (清洁代码的第25页)。该解决方案所指定的内容可能与其在活动域中实际表示的内容略有不同。

为了补救这一问题,我们需要在将某一类别应用于这些事物之前进一步对其进行定性。事物的行为、关系或属性是什么?不要用数据库或设计来描述它,因为它已经增加了清晰性的难度,但是它们将如何用交互的方式来描述自己,或者它们所执行的具体活动?

这是显而易见的:

  • 公司:有时作为供应商和客户参与这一行业的企业
  • 供应商:向客户提供某种东西;供应商是同义词;每个供应商可能与另一个供应商有联系,也可能没有。
  • 供应商模型:供应商是如何组织、附属和运作的;例如独立的、授权的、特许的
  • 供应商关系:明确的供应商关系,描述两个有组织、有关联或相互合作的供应商;每个隶属关系都有一个供应商模型,描述这种关系的性质。
  • 顾客:从供应商那里购买商品或服务或特权的人
  • 客户模型:?
  • 客户联系:?
  • 采购:供货商和顾客之间销售的记录
  • 可出售的商品:由供应商分发和出售并由客户购买的资源或物品
  • 可销售服务:由供应商为客户执行的活动
  • 可出售特权:给予客户合法机会使用某物或从事通常受供应商合法权利限制的活动
票数 0
EN
页面原文内容由Software Engineering提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://softwareengineering.stackexchange.com/questions/200684

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档