我了解到表中没有关于元组（例如行）的顺序概念，但根据wikipedia“元组是一个有序的元素列表”。这是否意味着属性确实有订单？如果是，为什么它们会被区别对待，是否可以在表中添加另一列（这就是为什么元组没有顺序）？
“在此表示法中，属性 - 值对可以按任何顺序出现。”这是否意味着属性没有顺序？
答案 0 :(得分：5)
可以说有两种元组。有“纯数学”，确实元组通常被定义为“有序的值列表”。因此，在数学理论中，谈到“元组中的第一个价值”等是有道理的。这可能是您的维基百科文章所指的意义或背景。
Haskell语言支持这种元组，例如，它还有一个fst（）运算符，用于从这样的元组中提取“第一”值。
但是，Codd意识到，在将元组列表的数学概念应用于数据管理领域时，这将是非常不切实际的。在数据管理中，他希望通过属性名称而不是顺序位置来表示值的可寻址性。实际上，想象如果从表中删除“五分中的第二个属性”的破坏性后果，现在所有解决同一个表的“第三个”和“第四个”属性的程序现在必须进行盘点和调整。因此在关系模型中，元组是命名值集合，因此，在数据关系模型中起作用的元组类型中，确实没有任何值排序的概念
然后正如其他回应中所指出的那样，SQL和它与关系理论的亵渎性偏差。在SQL中，元组和标题中的属性排序是非常有意义的，并且后果是无处不在的。在FK声明中，各个引用和引用属性的对应关系是顺序位置，而不是名称。其他情况是使用UNION和EXCEPT。取一个表T，X和Y列的类型相同。
SELECT X，Y FROM T UNION SELECT Y，X FROM T
本身并不是无效的，但标准规定结果中的列名是系统定义的（！）。 “执行合理的事情”并偏离此的实现，分别生成一个包含名为X和Y的列的表，然后面向其用户，结果是前一个表达式与
不同选择Y，X FROM T UNION SELECT X，Y FROM T
（因为列排序X，Y是除Y，X之外的另一个排序，因此标题不相等，因此表格不相等。）
SELECT X，Y FROM T EXCEPT SELECT Y，X FROM T
给出的结果会让很多新手SQL用户长时间不知所措。
答案 1 :(得分：4)
通常理解和使用的关系数据库模型的操作当然不依赖于关系中属性的顺序。关系变量的属性总是可以通过名称而不是位置来标识。但是，关系数据库理论中使用的符号并不总是指定属性名称（或属性类型），有时也暗示有序属性。这主要是书面符号而不是关系模型的结构或行为。在下面的参考文献中，对这些不同的“命名”和“有序”观点进行了更多的讨论。 http://webdam.inria.fr/Alice/pdfs/Chapter-3.pdf
E.F.Codd关于关系模型的最早的论文实际上提出了一个同时支持有序和无序版本关系的关系系统。从那以后，这个想法似乎已被遗忘或忽略，即使是科德本人。它不构成现代关系数据库理论的一部分。不幸的是，SQL肯定有列顺序的概念。它是SQL语法和语义的重要组成部分，它是每个SQL DBMS都支持的，以符合ISO SQL标准。 SQL不是关系型的，这只是它与关系模型的不同之处。 SQL模型和关系模型之间的尴尬差异会对使用SQL的关系模型的学生造成一定程度的混淆。