Sql really has two standards. There is the ANSI sql standard and then there is the DOUBLE standard. This example uses Sql Server 2005 and specifically the CTE (common table expression). Sql Server sees nothing wrong with this query that duplicates a column name. Something that no database should allow. SELECT employeeid,customerid as employeeid FROM orders From Bol on the CTE column_name 'Duplicate names within a single CTE definition are not allowed.The list of column names is optional only if distinct names for all resulting columns are supplied in the query definition.' But this query produces an error. WITH Emps (Emp, Emp) AS ( SELECT employeeid,customerid as employeeid FROM orders ) SELECT * FROM Emps Error: 'The column 'Emp' was specified multiple times for 'Emps'. But try this. And it works! WITH Emps (Emp, Emp1) AS ( SELECT employeeid,customerid as employeeid FROM orders ) SELECT * FROM Emps So what does Bol really mean in the column_name description. It means that the stupid and error prone idea of creating duplicate column names is perfectly ok in the query definition. It's only the outer reference names (the ( column_name [ ,...n ] ) that are going to be checked for duplicates. So the MS statement: 'The list of column names is optional only if distinct names for all resulting columns are supplied in the query definition.' is a recognition that its okay to screw up the query_definition as as long as you come away with distinct names in the CTE. In other words, give distinct names for the 'same' columns created in the query_definition with the same name. If you don't duplicate names in the quey_definition you can dispense with the CTE column name list totally. So not only is the MS statement a statement of guilt (don't expect us to correct duplicate column names when it first occurs, we'll catch it the 2nd time it comes around), it's also a statement of a double standard. One standard for an independent SELECT statement and another standard for a CTE! Double standards allow the initial error to propagate. Not what you want in a database. This is what a database should do when duplicate columns are declared. This is what Dataphor will do when you try this. select Orders {EmployeeID,CustomerID EmployeeID}; Error: Duplicate object name "EmployeeID". Only if you 'love' sql could you tolerate its nonsense ☺ . For more on the sql CTE see: 'Do you know what the Sql CTE is?' http://beyondsql.blogspot.com/2007/10/sql-whats-really-with-with.html
Dataphor SQL RAC (Relational Application Companion)
A site of hope for those looking for a true relational database system
- a one-one requirement constraint with dataphor (1)
- anatomy of sql server part I - what is a stored procedure (1)
- anatomy of sql server part II - the unit test as part of the database (1)
- anatomy of sql server part III - what does deferred name resolution really mean (1)
- censoring sql posts (1)
- creating an opposite constraint in dataphor (1)
- dataphor (2)
- Dataphor (7)
- dataphor # 13 a table as a parameter (1)
- dataphor - download and start working with it (1)
- dataphor - fixed sized word segments (1)
- dataphor # 10 sql mythology (1)
- dataphor # 11 string differences (1)
- dataphor # 12 trimming a string (1)
- dataphor # 14 sql the meaning of Update..From (1)
- dataphor # 15 views with substance (1)
- dataphor # 16 inclusive vs exclusive solutions (1)
- dataphor # 17 a visual look at ranking queries (1)
- dataphor # 18 data scrubbing using lists (1)
- dataphor # 19 create intervals over strings (1)
- dataphor # 20 browsing an sql window (1)
- dataphor # 21 an example of relational division (1)
- dataphor # 22 reusable procedures (1)
- dataphor # 23 repley to Michel (1)
- dataphor # 24 basics of the table type (1)
- dataphor # 25 extending the dense rank function (1)
- dataphor # 26 query a hierarchy with explode (1)
- dataphor # 27 combine strings with Split and Concat (1)
- dataphor # 28 constants and variables or sql and D4 (1)
- dataphor # 29 another example of relational division (1)
- dataphor #1 introduction (1)
- dataphor #2 splitting strings (1)
- dataphor #3 string concatenation (1)
- dataphor #4 comment (1)
- dataphor #5 comment (1)
- dataphor #6 formal definition (1)
- dataphor #7 sql: table this (1)
- dataphor #8 list to table (1)
- dataphor #9 table constraints (1)
- dataphor creating lists in a query (1)
- extracting numbers from a string with dataphor (1)
- jeff modens dynamic crosstabs for sql server (1)
- linq to sql the what and why (1)
- linq to sql as a window of opportunity to sql users (1)
- linq to sql should be important to sql users (1)
- linq to sql vs. older 4GL attempts (1)
- listing missing table item (1)
- Multiple cascade paths to the same table (1)
- RAC (4)
- RAC #1 comment (1)
- RAC #2 example (1)
- RAC #3 finding the Nth number in a string (1)
- RAC #4 Sql Server 2005 ranking functions vs. Rac ranking (1)
- sorting a delimited string by its numerical string parts (1)
- sql an example of extreme implicit conversions (1)
- sql can't handle complicated cascading updates (1)
- sql CTE should be a variable not a value (1)
- sql dense rank for identifying consecutive runs (1)
- sql is there really a table variable (1)
- sql ranking functions explained by relational types (1)
- sql server triggers are best set based (1)
- sql the idea of using substring to simulate lists (1)
- sql the undefined trigger in Sql Server (1)
- sql vs relational on tables (1)
- sql what the sql CTE covers up (1)
- types and procedures (1)
Monday, October 01, 2007
Sql - The Two Standards of the Sql CTE
Subscribe to:
Post Comments (Atom)
1 comment:
What namely you're saying is a terrible blunder.
Post a Comment