就像publication表可能通过subscriptions与person表相关联,或者company表可能通过employee与person表相关联一样,我想知道是否有一种描述性方法将company表与company_type表相关联。
下面是一些相关表的粗略(和简化)示例。
公司:
company_type:
{所需名称}:
而且,我意识到并非所有的关系都可以像subscriptions或employee那样简洁地命名,所以如果这里是这样的话,有什么好的经验法则可以避免与company_types之类的东西发生近名冲突呢?
其他详情:
就我们目前的情况而言,公司类型有些复杂。该行业有多个供应渠道和多个客户渠道,因此,虽然“供应商”是一个有效的company_type,一个供应商也可以“独立”,“授权”,或“专利”……或者三者的任何混合。
客户类型是非常相似的多方面的,为了进一步解决这个问题,单个公司可以同时拥有一些供应商和客户类型。
发布于 2013-06-06 15:58:07
你似乎在公司和company_type之间有着一对多的关系。一家公司可以是多种类型的?也许您可以给给定公司的类型集一个名称,“概要文件”,“分类”。
或者,你也可以描述这种关系,例如:
发布于 2013-06-06 16:18:20
当您对链接表没有明确的命名约定时,可能会出现此类问题。但是对于一定大小的数据库模式,有这样的约定确实有帮助,特别是当您有多个人处理该模式时。此外,您还应该有其他一些更通用的命名约定,比如何时使用单数和复数,如何命名主键和外键等等。
对于链接表,这可能会产生类似@Joppe建议的“技术”名称,或者产生像company_company_type或company_to_company_type这样的名称。但是,当你在你的组织内传达这个惯例时,这不应该成为很大的问题。一旦你做了决定,就一定要遵守那个约定。
发布于 2013-06-06 18:25:36
贴标签很容易。命名东西是很难的。很多时候,我们依靠相邻的术语或默默无闻的假设来提供技术上的区别,而不提供明确、明确的区分。引用一段无关上下文的话很好地说明了这一点:
下面这张便条在伦敦很有趣:“亲爱的先生,为什么从上星期六起我就没有得到你的爱的证据?”我一直焦急地等着。签名夏洛特·伯里。但当读者得知夏洛特·伯里夫人有一本名为“爱在新闻界”的小说,而这张纸条是写给她的打印机时,这种乐趣就消失了。
-卡兹利特·阿文,“文学和美术奇闻百科全书”,1853年
文章的来源来自无用衣橱
在各种形式和应用中,重言式指的是多余的用法:红血、种类、类别。没有通过使用特定的描述符来进行澄清。
分类法是一种包含一组描述事物的结构化规则的方案。这一方案可能是面向关系(亲子关系,专业化-泛化,继承-组合),但它可以组织起来,围绕其他识别策略。规则集中越早,规则就越不具体,而后面的规则提供了区别,否则就会有细微的区别。它描述了一个分类过程。模型可能是分类法的体现。
这是为某物的整体贴上标签以便计数或测量的过程。该主题满足一定程度的相似性,并缺乏任何丧失资格的特点,我们可以称之为同样的。
这些是事物的个别特征或特征。这可能包括人格或行为的品质。或者它们可能是物理属性。
为了解决眼前的问题,引用Bob叔叔的“干净代码”:
变量、函数或类的名称应该回答所有的大问题。它应该告诉你为什么它存在,它做什么,以及它是如何使用的。如果名称需要注释,则名称不会显示其意图。
Martin,Robert C. (2008-08-01)。清洁代码:敏捷软件工艺手册 (第18页)。皮尔森教育(美国)。Kindle版。
我们面前的是一个心理地图 (清洁代码的第25页)。该解决方案所指定的内容可能与其在活动域中实际表示的内容略有不同。
为了补救这一问题,我们需要在将某一类别应用于这些事物之前进一步对其进行定性。事物的行为、关系或属性是什么?不要用数据库或设计来描述它,因为它已经增加了清晰性的难度,但是它们将如何用交互的方式来描述自己,或者它们所执行的具体活动?
这是显而易见的:
https://softwareengineering.stackexchange.com/questions/200684
复制相似问题