Re: sql tables
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 11 Oct 2007 13:21:04 -0300
Message-ID: <470e4d35$0$14835$9a566e8b_at_news.aliant.net>
>
> and
>
>
> in
>
>
> table.
>
>
> a
>
>
>
> All of the "major" SQL DBMS products permit storing more than one identical
> row in a table. However, they provide several ways the database manager can
> protect the database from that event. The simplest is to declare a primary
> key for the table. This will also, however, protect against inserting two
> rows that differ, but have identical primary key values. Most often, that
> coincides with the intent of the manager.
>
>
>
>
> The question is moot. Table B and Table C have different headers, even
> though they contain the same columns. a row with values {2, 1} inserted
> into TableB would be different from the row that's already there.
>
> I'm not nearly as critical of SQL as the relational apologists in this
> forum. However, I think it's a weakness of SQL that it can't seem to make
> up its mind whether to use position or name as way of connecting values in a
> list to their "location". I see this confusion all over the language, and
> I think it's possible to do better. I am expecting relational apologists to
> point out specific languages that actually do better.
Date: Thu, 11 Oct 2007 13:21:04 -0300
Message-ID: <470e4d35$0$14835$9a566e8b_at_news.aliant.net>
David Cressey wrote:
> "paul c" <toledobythesea_at_ooyah.ac> wrote in message
> news:EbrPi.13483$Da.2157_at_pd7urf1no...
>
>>(note, I changed the thread subject) >> >>Bob Badour wrote: >> >>>David Cressey wrote: >>>... >>> >>>>An SQL DBMS manipulates tables, not relations or relational variables. >>> >>>Exactly. >> >>I presume David could just as well have said "an SQL DBMS manipulates >>SQL tables". Found (finally) a copy of some draft or other of the SQL >>standard at http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt . >> >>Not sure how this copy might differ from the official ones, but anyway, >>here's some of what it says in section 4.9 which seems to be about >>"Concepts": >> >> >>>4.9 Tables >>> >>> A table is a multiset of rows. A row is a nonempty sequence of >>> values. Every row of the same table has the same cardinality
>
> and
>
>>> contains a value of every column of that table. The i-th value
>
> in
>
>>> every row of a table is a value of the i-th column of that
>
> table.
>
>>> The row is the smallest unit of data that can be inserted into
>
> a
>
>>> table and deleted from a table. >> >> >>I'm wondering if there are popular SQL dbms's that follow this. For >>example, do any of them let me "insert", say, two "rows" that would be >>considered the same row if a table were a set of rows rather than a >>multiset of rows, giving, eg.: >> >>TableA: >>ColumnA >>1 >>1 >>
>
>
> All of the "major" SQL DBMS products permit storing more than one identical
> row in a table. However, they provide several ways the database manager can
> protect the database from that event. The simplest is to declare a primary
> key for the table. This will also, however, protect against inserting two
> rows that differ, but have identical primary key values. Most often, that
> coincides with the intent of the manager.
>
>
>>Also wondering about "i-th" values in rows. Does the above also mean that >> >>TableB: >>ColumnA ColumnB >>1 2 >> >>is not equal to >> >>TableC: >>ColumnB ColumnA >>2 1 >> >>(all other things being equal)?
>
>
> The question is moot. Table B and Table C have different headers, even
> though they contain the same columns. a row with values {2, 1} inserted
> into TableB would be different from the row that's already there.
>
> I'm not nearly as critical of SQL as the relational apologists in this
> forum. However, I think it's a weakness of SQL that it can't seem to make
> up its mind whether to use position or name as way of connecting values in a
> list to their "location". I see this confusion all over the language, and
> I think it's possible to do better. I am expecting relational apologists to
> point out specific languages that actually do better.
No apologies necessary. Received on Thu Oct 11 2007 - 18:21:04 CEST