专栏与字段:我使用这些术语的方式有误吗?


20

我在这里感到有些尴尬,我一直在完全互换地使用“列”和“字段”这两个术语,最近在技术讨论中引起了一些混乱。

有人告诉我,这是不正确的,应该是正确的(将每个术语转换为电子表格术语,忽略数据类型以及使数据库有用的所有其他内容):

  • 数据库列:类似于电子表格列
  • 数据库记录:就像电子表格行
  • 数据库字段:类似于电子表格“单元格”(特定行的特定列)

这是正确的吗?我可以发誓,列和字段比这更可互换使用。我当然去过。

因此,我们字段添加到表中,而是将添加到表中,并且字段仅在讨论记录中的数据时才相关?

关于列与字段的其他想法?

编辑:澄清一下,当前上下文是MS SQL Server。我在SQL Server之前的背景是MS Access,这可能会影响我对这些术语的使用。


对于其他情况:混淆出现在另一篇SO文章的评论部分:stackoverflow.com/questions/1398453/…
BradC


使用Postgres区分这一点很重要。一行可以包含多个记录。单个列可以有多个字段(在记录内)
a_horse_with_no_name

Answers:


31

关系数据库理论不包括“字段”一词的使用。EF Codd博士撰写了一系列论文,为RDBMS从未使用过该术语提供了理论基础。如果要检查,可以阅读他1970年的开创性文章《大型共享数据库的数据关系模型》

使用诸如域,表,属性,键和元组之类的术语。造成这种情况的一个原因是,他的论文主要涉及关系代数,而Codd并不认为特定实现在数据库中定义表的方式很重要。供应商以后会充实它。人们还必须了解,从历史上看,RDBMS是从它们之前的现有分层数据库和网络数据库演变而来的,而且RDMBS的内部工作仍必须与数据的组织和存储有关。

在常用的情况下,您只需做一下Google搜寻就可以轻松地验证这一点,字段和列同一回事。

诸如DBase,Access和Filemaker之类的PC数据库通常使用“字段”而不是“列”。“属性”是另一个可以互换使用的术语。

例如,这是有关在表中添加“ 字段 ” 的MS Access手册的链接。显而易见,在MS Access中,“字段”等同于“列”。

Dbase和Filemaker Pro也是如此。

有时人们将特定行中的特定值称为“字段”,或更恰当地称为“字段值”,但这在引用列或等效列概念时不正确使用“字段”。确实会引起一定程度的混乱,因为人们多年来一直使用“字段”来表示不同的事物。在关系理论中,单个原子值称为“基准”。

如果有人说“字段”是关系数据库中的一个值,而不是与列相同,那是他们的意见,因为“字段”不是关系数据库白话的一部分。它们是非非非,但是,在整个数据库世界中,字段通常用于表示列。

话虽如此,项目和团队通常必须对他们如何在项目中使用特定术语产生理解,以免造成混淆。

您没有错,但是您也可以决定简单地遵循所使用的约定,或者完全避免使用字段字段来支持“列”。对于关系数据库,“表”和“列”是DDL中存在的构造块,最好仅使用这些术语,避免使用未使用或未明确定义的“字段”。


是的,平台可能是相关的,我相信不同的开发人员实际上可能会稍微不同地使用这些术语。在我的特定情况下,这很重要,这是MS SQL Server。
BradC 2014年

像Joe Celko这样的人往往不同意字段和列是同一件事。
a_horse_with_no_name 2014年

3
我会向对RDBMS实践感兴趣的任何人推荐Joe的书。见过他几次后,他会坚决地避免使用领域代表不同的事物而引起的混乱,这不足为奇。这并没有改变该术语的历史,也没有改变人们在数据库中使用“字段”作为列的事实,这一事实早于他阻止人们采用PC数据库术语的追求。
gview

有时,同一供应商可能会给术语带来混乱。例如,Microsoft在这里说:“列是表中垂直对齐的单元格的集合。字段是存储一条信息的元素,例如Received字段。通常,表中的列包含以下值:一个字段。”。当然,这里的背景是Outlook,但是人们可能很容易受到这种说法的影响。msdn.microsoft.com/en-us/library/office/ff866450.aspx
drumsta

8

较旧的SQL:92fields称为datetime项的组件:

“日期时间项中的字段”,指定可以组成日期时间值的字段;日期时间值由这些字段的子集组成

这里的字段是年,月等等,以及术语 field在文档的其余部分似乎没有其他含义。

较新的SQL:2003标准具有以下内容:

列,字段和属性

术语“列”,“字段”和“属性”分别以类似的方式表示表的结构组件,行类型和结构化类型。由于表的结构由一个或多个列组成,因此行类型的结构也由一个或多个字段组成,而结构化类型的结构也由一个或多个属性组成。每个结构元素,无论是列,字段还是属性,都主要是与声明的类型配对的名称。

然后:

F由字段描述符所描述。字段描述符包括:
—字段名称。
—声明的F类型的数据类型描述符
。— F在仅包含它的行类型中的顺序位置。

此列与定义为:

C由一列描述符描述。列描述符包括:
—列名。
—列名是否为实现相关名称。
—如果该列基于某个域,则该域的名称;否则,为声明的C类型的数据类型描述符。— C
的值(如果有)。C
的可空性特征
。— C在包含它的表中的顺序位置。
... (和更多)

然后稍后再介绍表格时:

表格是具​​有一个或多个列的行的集合。行是行类型的值。同一张表的每一行都具有相同的行类型。表中每一行的第i个字段的值就是表中该行的第i列的值。该行是可插入表中和从表中删除的最小数据单位。

(强调我的)。这似乎支持您在问题中写的内容:特定行的特定列


6

多少个天使可以绕着大头针跳舞?

改正您的人可以自己改正。

  • 表=关系

  • 行=元组

  • 列=属性

  • 域=数据类型

请参阅此处有关关系数据库的Wikipedia条目。

我在一家航空公司工作过,根据您是在与飞行员/乘务员,工程师还是市场营销人员进行交谈,可以用三种不同的方式使用“飞行”一词。

  • 飞行员/服务员:一次“飞行”从基地起飞并返回(即两次起飞和两次着陆),
  • 工程师:一个起飞和一个着陆可以是测试,修理,训练(例如,一个机场回到同一机场)或“一条腿”,即从一个机场到另一个机场-“平民”通常称为航班,在“我明天要乘飞机回家”)中,

  • 市场营销:根据合同,为期六个月(通常是按季节或按季节进行)从/到给定机场的“航班”系列。

电子表格的类比即使在合理的技术演讲中也足以胜任99.99%的案例(除非是关系代数的教授)。纠正您的人是否正确使用“ whom”一词?99.99%的人没有,这真的没有关系。


2

我通常交替使用“字段”和“列”,最近倾向于“列”。我还没有单独听到“字段”这个术语来表示“数据”。我也没有听过“属性”一词来表示“字段”或“列”。列/字段具有属性,例如,可以通过FieldInfo类访问。

我相信“列”只是术语的演变。桌面数据库(xBASE,MSAccess)通常使用“字段”。M204使用“字段”。此“字段”术语已引入MSOffice xml和其他文件中。Oracle文档(抱歉,我不会再发布任何链接了)和MSSQL在整个文档中交替使用“字段”和“列”。Sybase(现为SAP公司)主要在文档中使用“列”,但有时使用“字段”。

只要您的工作组同意一个条件,哪个条件都没关系。这是“其他任何名字引起的”综合症。


1
您还没有听说过(或阅读过)“属性”,“元组”,“关系”等术语吗?
ypercubeᵀᴹ

@ypercube:GDD在日常开发中可能意味着。
siride

2

因此,我意识到这是一个古老的问题,但是我经常听到这个问题。我对此的看法来自我们的数据团队与开发团队的参与。开发人员肯定在屏幕上显示的记录中具有字段,并且这些字段包含可以频繁映射到具有特定行的列的数据。但是,在许多情况下,用于访问数据的关系方法可以更改在特定字段中的特定屏幕上显示的内容。

我记录的是数据提供的当前值的表示。随着时间的流逝,这些值可能会更改,因此记录也会更改。支持现在和给定时间的数据可以轻松地存储在一组表中。数据之间的关系决定了在任何给定时间组成记录的含义。

派生字段的逻辑是可以随时间变化的。例如,一名雇员被聘为Susan Jones,而她在2010年12月1日被雇用为#101商店的销售员,并向Bill Anderson担任商店经理。作为一家进取的公司,他们还为每位员工分配了一名导师。苏珊的导师是玛丽·菲利普斯(Mary Phillips)。玛丽·菲利普斯(Mary Phillips)是一家商店经理,但她还是Susan在其中工作的商店的区域经理。2011年11月10日,Susan晋升为商店经理。我们不知道Bill怎么了,但Susan现在是商店经理。

我们有一个员工表,其中包含姓名,人数,雇用日期,职位和位置。

我们有一个导师表,其中包含导师和他们所指导的员工的员工编号,以及描述导师关系开始和结束的日期。

我们有一个区域表,其中包含该区域的名称和分配的经理编号。

我们还有另一个位置表,其中包含地址,描述,区域和经理编号。

我在显示商店信息的屏幕上可能有一个商店经理字段。商店经理的值不是数据库字段,而是一个可随时间变化的可计算值。一个人的经理也可以改变。支持它的数据仍存储在列中,但是列之间的关系已更改,并且当出于特定目的而进行组合时,该字段将成为字段。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.