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.
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.
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.
Good afternoon all,
I have two columns that I am trying to sort into a table, memberid and then total spend. When I run the following query:
Select Memberid, totalspend
from Table
order by totalspend;
my data returns the way that I expect it to. When I try and run:
Select MemberID, TotalSpend
into SampleTable
from Table
order by TotalSpend
SQL does not retain the sort.
The research that I have done so far suggests that the select into statement should work but for some reason it it not. I have tried converting the Totalspend to a float, int or varchar and still no luck.
I need my data sorted so that I can perform calculations on the table based on top x rows.
I am currently using SQL Server 2017.
Thank you,
Richard
SQL does not retain the sort.
This is soooo true. SQL tables represent unordered sets. No ordering. Get it?
That said, you can sort of impose order on the data. Here are two methods:
You can define a primary key. The data is physically sorted on the data pages (in SQL Server) based on the primary key.
You can define an identity column. In conjunction with order by, the identity column will capture the ordering.
Strictly speaking these have no effect on the result set from a query on the table. Instead, they are methods for storing the ordering in the data.
What is true about tables being unordered is also true about result sets. So if you run:
Select MemberID, TotalSpend
from SampleTable;
The result set is unordered. That means that even with a primary key or an identity column or both, SQL Server can return the rows in whatever order it so desires. It can even return the data in different orders on different runs.
Fixing this is easy. If you want the data in a particular order, simply add the following to your query:
order by TotalSpend
If you have an index on the column, then the sorting would normally use the index (unless the data is very small), so very little overhead would be incurred.
I am working on a plsql procedure where i am using an insert-select statement.
I need to insert into the table in ordered manner. but the order by i used in the select sql is not working.
is there any specific way in oracle to insert rows in orderly fashion?
The use of an ORDER BY within an INSERT SELECT is not pointless as long as it can change the content of the inserted data, i.e. with a sequence NEXTVAL included in the SELECT clause. And this even if the inserted rows won't be sorted when fetched - that's the role of your ORDER BY clause in your SELECT clause when accessing the rows.
For such a goal, you can use a work-around placing your ORDER BY clause in a sub-query, and it works:
INSERT INTO myTargetTable
(
SELECT mySequence.nextval, sq.* FROM
( SELECT f1, f2, f3, ...fx
FROM mySourceTable
WHERE myCondition
ORDER BY mySortClause
) sq
)
The typical use case for an ordered insert is in order to co-locate particular value in the same blocks (effectively reducing the clustering factor on indexes on columns by which you have ordered the data).
This generally requires a direct path insert ...
insert /*+ append */ into ...
select ...
from ...
order by ...
There's nothing invalid about this as long as you accept that it's only worthwhile for bulk data, that the data will load above the high water mark only, and that there are locking issues involved.
Another approach which achieves mostly the same effect, but which is more arguably more suitable for OLTP systems, is to create the table in a cluster.
The standard Oracle table is a heap-organized table. A heap-organized table is a table with rows stored in no particular order.
Sorting has nothing to do while inserting rows. and is completely pointless. You need an ORDER BY only while projecting/selecting the rows.
That is how the Oracle RDBMS is designed.
I'm pretty sure that Oracle does not guarantee to insert rows to a table in any specific order (even if the rows were inserted in that order).
Performance and storage considerations far outweigh ordering considerations (as every user might have a different preference for order)
Why not just use an "ORDER BY" clause in your SELECT statement?
Or better yet, create a VIEW that already has the ORDER BY clause in it?
CREATE VIEW your_table_ordered
SELECT *
FROM your_table
ORDER BY your_column
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