I defined seq_id column as NUMBER(10), when I select from this table, the record with seq_id = 10 is after shown 1 - not after 9.
How should I make the rows get sorted in numeric order? I know order by seq_id will make it numeric order. But I have seen other tables their counter & seq_id are default in numeric order.
If you don't specify an order by clause the order in which rows are returned is arbitrary. If you care about the order of rows, you must use an order by.
For most tables in simple select statements without a where clause, rows will usually be returned in the way they are physically ordered on disk. For small tables that never undergo deletes, never have updates that cause row migration, and never have multiple threads doing inserts, that physical order is likely to correspond to the numeric order of the sequence. But that is not something that you should depend on.
Related
When I insert a row in a Firebird database, it doesn't show at the end of the table and it inserted before other row. Why is this?
Firebird doesn't use clustered tables, nor does it order data by insert. When you insert a row, Firebird adds the row to the first datapage of the table it can find that has sufficient space available. As a result, it may end up anywhere relative to other rows of the table.
If you want to enforce a specific order to the data you view, you need to add an order by clause to your select statement, specifying by which columns you want to order the data. Without an order by, the order of the result of a select is not deterministic, and may be the result of physical order in data pages, order of data in an index used to find rows, and other factors.
Does the sequence of records in SELECT QUERY in result always the same?
I mean that if the first result of operation returns the following sequence:
first record
second record
third record
All other select * from t queries always return records in the same sequence.
A SQL query -- like a SQL table -- represents an unordered set. There is no ordering, unless an ORDER BY is present for the outermost SELECT.
As an unordered set, the same query can return results in a different order each time it is run.
So, if you want results in a particular order, use ORDER BY.
I should add that if multiple rows have the same key, then these rows can appear in any order, even with an ORDER BY. In general, you should ensure that the keys in the ORDER BY uniquely define each row (say by including the primary key as the final key).
I have a column named id in my SQLite database which is auto-increment, Primary Key, Unique.
Is the result of the following query guaranteed to be the smallest value of id in the database and does this correspond to the "oldest" (as in a FIFO) row to be inserted?
SELECT id FROM table LIMIT 1
The SQLite documentation is quite explicit:
If a SELECT statement that returns more than one row does not have an
ORDER BY clause, the order in which the rows are returned is
undefined. Or, if a SELECT statement does have an ORDER BY clause,
then the list of expressions attached to the ORDER BY determine the
order in which rows are returned to the user.
The LIMIT is applied after an ORDER BY would be, so I don't think it affects the application of this statement.
Hence, if you want the first row, use ORDER BY:
SELECT id
FROM table
ORDER BY id
LIMIT 1;
Note that if id is a primary key, this will add basically no overhead.
I should emphasize that in practice you are probably going to get the smallest id without the ORDER BY. However, it is a really, really bad idea to depend on behavior that directly contradicts the documentation.
Is the result of the following query guaranteed to be the smallest value of id in the database
Yes. However if the table is empty or the id column is NULL, it could also return NULL
and does this correspond to the "oldest" (as in a FIFO) row to be inserted?
No, there's no guarantee of that.
I have a table containing samples. The inserted samples are already naturally ordered by the timestamp.
My question is this - when I SELECT from the table do I have to use the ORDER BY clause to ensure the fetched samples are ordered by the timestamp?
Rows in a relation database are NOT sorted (Picture them as balls in a basket. Which one is the "first"?)
The only way (really, the only) to get a consistently sorted result is to use ORDER BY.
You cannot rely on side effects of joins, group by. UNION, index retrieval or similar operators. They will never guarantee an order. The DBMS is free to choose to return the rows in whatever order it thinks is the fastest unless you specify an ORDER BY.
If an HSQLDB table T has a column C as primary key, or has any index on that column,
SELECT FROM T ORDER BY C
will return ordered rows without extra ORDER BY processing.
If there is a condition on the select, which uses an index on a different column, you can still force the use of the index for ORDER BY:
SELECT FROM T WHERE <some condition> ORDER BY C USING INDEX
But in this case, you should only use USING INDEX if most of the rows of the table will be returned. Otherwise it is better to leave the engine use the other index to reduce the table scan time.
USING INDEX is ignored if there is no index to use for ORDER BY.
I have a table with a timestamp column and a few other char columns. I have ordered the information in the table by the timestamp but due to the fact that there are more records on the same timestamp I do not know if the order displayed is the order they were inserted in the table.
Sadly there is no index on the table so apart from the timestamp there isn't anything else I could use to order them by.
Example:
Timestamp | Foregin table | Foreign table value
2012-10-09 19:29:50.000 | tableA | "random string here"
2012-10-09 19:29:50.000 | tableA | "different string here"
2012-10-09 19:29:50.000 | tableB | "another random string here"
2012-10-09 19:29:50.000 | tableC | "string here"
2012-10-09 19:29:50.000 | tableD | "another string here"
The query that I run is something like this:
SELECT *
FROM TABLE
WHERE Timestamp BETWEEN 'x' and 'y'
ORDER BY Timestamp
Reviewing my results I assume, but I am not sure, that the query returns the data ordered by the specified column and continues ordering of the results by the next column/columns, in case there are more than 1 column, in an ascending manner (maybe by length of text or by alphabetical order).
Could you please help me clarify this situation as it is very important for me to find out the order.
SQL Server in general has no order guarantee for queries not specifying an ORDER BY. So a SELECT * FROM Tbl can essentially return the rows in any random order. Because of how the data is stored on disk, if you have an empty cache and no other activity going on on the server, you will get the data in on-disk order with a fairly high probability. That probability goes down dramatically if there are other concurrent queries on your server and if the cache is not empty. So while you might observe a specific behavior in your tests, you will not get the same behavior in production.
That said, if you need the rows to come back in a specific order you need to specify an appropriate ORDER BY clause. In the case above you could use ORDER BY [Timestamp], [Foreign table], [Foreign table value] to make sure that the records always come back in the same order. If your query contains more columns and none of them is unique you need to add all those to the ORDER BY too. But keep in mind that sorting gets more expensive the more columns are involved.
SQL Server will order the results using the explicit ORDER BY clause and gives no gaurantees as to the order of results for which all columns in the ORDER BY clause are equal.
If you want it to then order by one of your char columns alphabetically you need to specify that in your ORDER BY clause. It may be the case that your current results set is sorted in this way but it is highly unlikely that this will continue indefinitely.
Tables in databases are inherently unordered. This answer is a clarification of Sebastian's answer (the clarification is too long for a comment).
The return order is not random. It is arbitrary. And, it can change from invocation to invocation. On a table that has deletes as well as inserts, then later records can be interspersed on data pages with earlier records. Once again, there is no concept of ordering within a data table. Ordering is only part of query statements.
A bigger factor than other queries running on the system is multi-threading (and to a less extant multiple partitions).
If you have an empty cache, a query that does not access the table through an index, no deletes in the table, a single partition, and a single threaded system, then the data would normally be returned in insert order. Even in this case, though, there are no guarantees. If you want the data in a particular order, use order by. If you don't want a performance hit, include an identity primary key and use that for the ordering.