- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Wed, 20 Oct 2010 10:23:09 -0400
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: RDB2RDF WG <public-rdb2rdf-wg@w3.org>
* Richard Cyganiak <richard@cyganiak.de> [2010-10-19 23:48+0100] > http://www.wiscorp.com/sql200n.zip > > This looks like a 2006 draft of SQL:2008. I don't know how it > differs from the final version, and I don't know why it is available > for download for free, given the price of the real standard. > > Anyone who doesn't have a copy of SQL:2008 handy might find this useful. > > Part 1 defines basic terminology (client, server, schema, table, > column etc) and says what it in SQL Core. I guess it comes as no surprise that SQL speaks of tables, rows and columns (as opposed to relations, tuples and attributes/values): 3.1.1.27 table: An unordered collection of rows having an ordered collection of one or more columns. Each column has a name and a data type. Each row has, for each column, exactly one value in the data type of that column. Per Richard's earlier comments, should we use this language (table, row, column, name, data type) for our documents? I notice this definition elides the uniqueness of the column names, which is true of SQL but not of relational algebra. Are there any use cases which motivate us going beyond the relational data accessible to SQL, e.g. the two name attributes in:? ┌────┬──────┬───────┐ │ ID │ name │ name │ ├────┼──────┼───────┤ │ 7 │ Bob │ Smith │ └────┴──────┴───────┘ > Part 2 defines the SQL language. > > Part 11 defines the Information Schema (the standard way of finding > out which tables and columns are available in a database). > > The other parts are not relevant for SQL Core. > > Best, > Richard > -- -ericP
Received on Wednesday, 20 October 2010 14:23:56 UTC