|
|
Posted by Tony Rogerson on 02/03/06 14:22
Interesting, so all the research on 'ordered sets' amounts to nothing?
Yet another example of your doctorine, Codd gave us great foundations to
work on he did not hand down doctorine.
Google 'ordered sets' for some ***research***.
> You do not know the RM or the SQL standards, so you think that SELECT
> TOP 1 is not a dialect, that you must have physically contigous storage
> at all, etc. The kind of code you are writing mimicks the way we used
What if an application requires the top 10 products then? How would you
achieve this? Would you really pass back the 50,000 products to the
application or middle tier (that doesn't scale by the way) or just easily
use SELECT TOP 10 .. FROM... ORDER BY product_sales_units DESC.
Tony Rogerson, SQL Server MVP.
"--CELKO--" <jcelko212@earthlink.net> wrote in message
news:1138833567.598027.131260@g14g2000cwa.googlegroups.com...
>>> Perhaps though I am missing your point celko. If so, could you be more
>>> precise? <<
>
> Just read any book on RDBMS. The Relational model is based on sets.
> By definition sets have no ordering. Dr. Codd is a good place to
> start.
>
> Thus, an SQL implementationis free to use PHYSICAL storage in any way
> it wishes. Contigous storage such as SQL Server is currently using is
> only one approach. Teradata uses hashing and can re-arrange physical
> storage without telling you. Ingres has several kidns of indexing and
> can change the method used based on a statistics. Several other
> products will insert new rows over the storage used for deleteed. The
> SAND engine assembles rows from compressed bit vectors and has no
> physically
> contigous storage at all.
>
> You do not know the RM or the SQL standards, so you think that SELECT
> TOP 1 is not a dialect, that you must have physically contigous storage
> at all, etc. The kind of code you are writing mimicks the way we used
> to write for magnetic tape file systems. You need to get more abstract
> in your thinking.
>
Navigation:
[Reply to this message]
|