in reply to Re: Increase a value inside MySQL query using perl
in thread Increase a value inside MySQL query using perl

a database accessed by SQL has no concept of "first one" or "next one". Whichever record is returned "first" (or "next") is not strictly defined.

While the second statement is accurate, the first is not. At least, not without context.

Technically, there most definitely is an order, as the data is stored in files, and those records do not usually move. And when they do move, there is an identifier in place saying so, until a specific operation removes it.

So, though not strictly defined, there is definitely a first record, and that is why it is always returned first in a vanilla statement. However, it cannot be relied upon because it can change from an outside statement affecting storage, or even a recent caching that included an order by (or a group by, which does its job via a binary sort.)

If you'd like to be technically correct, you would drop the words "a database accessed by" and use the KISS* method, "there is nor first or last in SQL, without an explicit ORDER BY clause."

--

*Keep It SQL, Stupid

  • Comment on Re^2: Increase a value inside MySQL query using perl

Replies are listed 'Best First'.
Re^3: Increase a value inside MySQL query using perl
by CountZero (Bishop) on Oct 14, 2015 at 18:51 UTC
    That is exactly why I put "first one" and "next one" in "quotes".

    And I said the DB does not have the concept of first or next (meaning the next one in an ordened sequence). It is simply not existing in an SQL database whose working is based on set-theory. You have to impose order yourself. So the OP by not defining the ordering was relying on a mechanism that does not exist when he referenced an operation on a sequence of records.

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

    My blog: Imperial Deltronics
[reply]

      I'm just making a technical note here. You are referring to the SQL paradigm, as opposed to a database concept. Instead of mentioning the rdbms and then putting words in quotes, don't mention the rdbms at all. :)

      I will disagree with you partially, about the rdbms not having those concepts. Row order is important to RDBMS's. For example, Oracle has ROWID which is the actual location of the record itself. (And row pointers if they move!) SQL Server organizes table data based on an index (as does Oracle in IOTs.) Other RDBMS likely have similar concepts. So, there is such a concept in the DB, and a program can make use of it too. It's only SQL that doesn't have the concept.

[reply]
        Does a DB wih ROWIDs serve the records in ROWID-sequence?

        Row order should not be important at all, and a DB where this is important is somehow doing it all wrong.

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

        My blog: Imperial Deltronics
[reply]

In Section Seekers of Perl Wisdom