I want to sort my table permanently by using ID column in ascending order.
select * from CLAIMS order by ID asc; gives me the result in ascending order.
But I want to permanently change my table. I am using SQL Management Studio 2014.
While there's no way to guarantee ordered result without an ORDER BY clause on your query, but you can store the rows in a sorted order to enable the SQL Server to run
select * from CLAIMS order by ID asc;
without having to perform a sort every time. To to that simply create a clustered index with ID as the only or the leading column.
EG
alter table CLAIMS add constraint PK_CLAIMS primary key clustered (ID)
or
create unique clustered index AK_CLAIMS on CLAIMS(ID)
I want to sort my table permanently
You just can't. SQL tables represent unordered set of rows. There is no inherent ordering of rows in a table, as you seem to assume.
If you want the rows returned in a given order for a given query, then do add an order by clause to the query:
select * from claims order by id
If you don't provide an order by clause, the database is free to return the rows in whichever order it likes. The ordering you see today for a given query might change unexpectedly in the future.
Related
How would I sort a table in SQL Server when it is opened? My table has an autonumber field that increments sequentially and it is the primary key field also.
I'd like to have another numeric field sorted smallest to largest and then have the autonumber field to use the auto field number relying on the other numeric field.
The image shows how the table is currently sorted. I'd like to have the table sorted when it opens from ssms by the second column.
Thanks,
Jeff
the sort depends on cluster index, by default any primary key will create a clustered index on that column so the table will be sorted based on it.
if you want to sort the table based on another column you need to drop your cluster index and create it on the second column.
How would I sort a table in SQL Server when it is opened?
You cannot. SQL tables represent unordered (multi)sets. They have no inherent ordering. To get data in order, you need an explicit order by clause:
select t.*
from t
order by col2 asc;
For performance, you want an index on (col2).
If you declared the second column as a descending clustered index, then in practice you would probably see smaller values first. However, even with a clustered index, SQL Server does not guarantee that a SELECT with no ORDER BY will return the rows in any order. Period. There is no guarantee.
if suppose we have written a SQL select command without using order by clause then what will be the column on which the sorting will done while displaying records of select command...
create table test
(
ID int identity (1,1) primary key,
em_id int,
name varchar(20),
address varchar(20)
mobile number int
)
suppose the table is like above structure and select command like
select * from test
then how can i check the column name on which the sorting is done by sql..
In a query like this:
select *
from test;
The result set is not sorted.
SQL tables represent unordered sets. Running the query multiple times can result in the same result set -- but with the rows in a different order.
If you want a specific ordering in the result set, you need to include an order by.
You may be confusing "ordering" with the clustered index. If so, you can find the keys in a clustered index (if one exists) using the system metadata tables. But the data is not guaranteed to be returned by the clustered index unless you have an order by in the query.
If you want a specific ordering in the result set, you need to include an order by clause.
By default order by(if you specify order by clause) is in ASC order.
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.
Insert 200 data througn for-loop into sqlserver 2000 database, the order change, why ?
When I use mysql, it doesn't have the matter.
i mean:
when you insert 2, then insert 3, then insert 1, in mysql you will see 2,3,1 like the order you insert. But in sqlsever2000 that may not.
The order in which rows are stored doesn't really matter. Actually SQL tables don't have any ordering. If order matters to you, you need to query using an ORDER BY clause.
There are no guarantees on the order of the results of a select statement, unless you add an ORDER BY clause. You might get the results back in the order of insertion, but it's not guaranteed.
If you have an index on the table, it might appear that your data is being ordered in a way that you're not expecting. Normally, you'll just have an identity column as your surrogate primary key, which means your inserted data will show up in "order" if you just do a select *, but if you have indexes on other columns the data might be ordered differently when you do select *.
You can control physical ordering by creating a clustered index on that columns. Only one clustered index is allowed per table. Cluster index make sure when you perform SELECT you will always get data in order which was defined when creating cluster index.
A basic simple question for all of you DBA.
When I do a select, is it always guaranteed that my result will be ordered by the primary key, or should I specify it with an 'order by'?
I'm using Oracle as my DB.
No, if you do not use "order by" you are not guaranteed any ordering whatsoever. In fact, you are not guaranteed that the ordering from one query to the next will be the same. Remember that SQL is dealing with data in a set based fashion. Now, one database implementation or another may happen to provide orderings in a certain way but you should never rely on that.
When I do a select, is it always guaranteed that my result will be ordered by the primary key, or should I specify it with an 'order by'?
No, it's by far not guaranteed.
SELECT *
FROM table
most probably will use TABLE SCAN which does not use primary key at all.
You can use a hint:
SELECT /*+ INDEX(pk_index_name) */
*
FROM table
, but even in this case the ordering is not guaranteed: if you use Enterprise Edition, the query may be parallelized.
This is a problem, since ORDER BY cannot be used in a SELECT clause subquery and you cannot write something like this:
SELECT (
SELECT column
FROM table
WHERE rownum = 1
ORDER BY
other_column
)
FROM other_table
No, ordering is never guaranteed unless you use an ORDER BY.
The order that rows are fetched is dependent on the access method (e.g. full table scan, index scan), the physical attributes of the table, the logical location of each row within the table, and other factors. These can all change even if you don't change your query, so in order to guarantee a consistent ordering in your result set, ORDER BY is necessary.
It depends on your DB and also it depends on indexed fields.
For example, in my table Users every user has unique varchar(20) field - login, and primary key - id.
And "Select * from users" returns rowset ordered by login.
If you desire specific ordering then declare it specifically using ORDER BY.
What if the table doesn't have primary key?
If you want your results in a specific order, always specify an order by