在sqlite3中,我可以强制将两列别名为相同的名称,如以下查询所示:
SELECT field_one AS overloaded_name, field_two AS overloaded_name FROM my_table;
它返回以下内容:
overloaded_name overloaded_name --------------- --------------- 1 2 3 4 ... ...
… 等等。
但是,如果我使用相同的语法创建一个命名表,则会在别名之一后附加一个:1:
:1
sqlite> CREATE TABLE temp AS SELECT field_one AS overloaded_name, field_two AS overloaded_name FROM my_table; sqlite> .schema temp CREATE TABLE temp( overloaded_name TEXT, "overloaded_name:1" TEXT );
我运行原始查询只是为了看是否可行,我很惊讶它被允许。有什么充分的理由这样做吗?假设没有,为什么根本不允许这样做?
编辑 :
我应该澄清:问题是双重的:为什么允许表创建成功,并且(更重要的是)为什么首先允许原始选择?
另外,请参见上面有关表创建的说明。
我可以强制两个列使用相同的别名…为什么首先要使用[this]?
这可以归因于兼容性的束缚。在SQL标准中,不建议使用任何东西。标准的早期版本允许表表达式的结果包含具有重复名称的列,这可能是因为有影响力的供应商允许这样做,这可能是由于包含错误或缺少设计功能而没有准备的冒着破坏客户代码的风险(再次是兼容性的束缚)。
复制表中的列名有什么用?
在关系模型中,每个关系的每个属性都有一个在相关关系中唯一的名称。仅仅因为SQL允许重复的列名,但这并不意味着作为SQL编码器,您应该使用诸如feature之类的功能;实际上,我要说的是您必须保持警惕,不要错误地调用此功能。我无法想到在表中具有重复的列名的任何正当理由,但我能想到许多明显的不好的理由。这样的表不是关系,也不是一件好事!
为什么[基本]表创建成功
毫无疑问,这是对SQL标准的“扩展”(即有意违反),我想它可以被认为是一个合理的功能:如果我尝试创建具有重复名称的列,系统会通过在后缀序号后自动消除它们的歧义。实际上,SQL标准指定了一种依赖于实现的方式,以确保表表达式的结果不会 隐式地 具有重复的列名(但是,正如您在问题中指出的那样,这并不妨碍用户 显式 使用重复的列名。AS条款)。但是,我个人认为禁止重复名称并引发错误的标准行为是正确的。除了上述原因(即,同一表中的重复列没有用处)之外,在不知道系统是否认可该名称的情况下创建对象的SQL脚本也很容易出错。
AS