I have a student table with 8 records in columns [name, address, TotalFees].
Even though I execute two same ORDER BY queries on single table I get two different outputs. I have attached the screenshot below.
Same query on same table with different output:
The issue that you have is that the keys for the order by do not uniquely define each row. In particular, "khar" is repeated for most of the rows (your results suggest that you are using a case-insensitive collation).
In SQL databases, the sort is not stable. A stable sort is one that preserves the original ordering of values with the same key. Because the sort is not stable, the results -- for identical keys -- can come out in any order.
Why isn't the sort stable? That is easy in retrospect. SQL tables and result sets represent unordered sets. There is no initial ordering, so the sorting is not stable.
The normal way to address this is to include a unique id as the final key in the order by: order by address, id. With your data, though, it is unclear what the unique key is.
Combination of Address and Name won't produce duplicates so you can try this,
select *From student
order by address,name
select top 3 * From student
order by address,name
Related
I wanted to know if the row order returned by a query mattered?
I'm not using a SQL service yet, just working with plain tables and Excel.
For example if I do a left join on two tables, my take is that all the rows from the left or first table to be mentioned will be the first ones in my resulting table, whether there are coincidences on the right one or not. But a classmate ordered the results so he placed the rows with coincidences first and the ones without, with null values, at the end.
SQL tables represent unordered sets. SQL results sets are unordered unless you explicitly have an ORDER BY for the outermost SELECT.
This is always true and is a fundamental part of the language. Your class should have covered this on day 1.
The results from a query without an ORDER BY may look like they are in a particular order. However, you should not depend on that -- or, you depend on that at your peril. The rule is simple: without an ORDER BY, you do not know the ordering of the result set.
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).
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 have a table which has ShipCountry, ShipCity and Freight column in SQL database. I tried to retrieve data from that table by using the below query.
Select ShipCountry from CountryDetails Group by ShipCountry
If i run this query i am getting results in Ascending order. Instead of this i need data in database order. How to achieve this through SQL query?
Note: If i run the below query, it will return the data in Database order. I am getting sorted data when i added group by clause in my query.
Select ShipCountry from CountryDetails
The use of group by for ordering is improper .. (group by is for aggregation function as min, max or count)
if you need a specific order use order by instead
Select ShipCountry from CountryDetails Order by ShipCountry
otherwise if want not order use simply
Select ShipCountry from CountryDetails
Remember that the values store in db have not a proper order ..and are selected in the sequence used for retrive the data.
Each time you need an order you must esplicitally use order by
for avoid "redundant values" .. use distinct and not group by eg:
Select distinct ShipCountry from CountryDetails
As already has been stated, what you describe might lead to unexpected results fro your end users.
Let's assume you have a table without any indexes or keys (A so-called heap). A heap pretty much can be compared to a phone book (yeah, I've been around for a while) consisting of hundreds of pages, on which information is randomly ordered. A heap is exactly that; A lot of randomly ordered data. Whenever you query from such a table, the query analyzer will do its very best to figure out what the fastest way to deliver the data is.
Such decisions from the query analyzer are guided by statistics; a collection of metrics about the data and the distribution thereof. SQL Server uses these statistics to figure out the cardinality (the uniqueness of values), and thus pick the fastest way to return data.
When you simply issue a SELECT * FROM myTable on a heap, those statistics will determine the order in which your data is returned. However, this also means that over time, the statistics will change, as more data flows into the table. This has the effect that the sort order of your data today is not necessarily the sort order in which the data is returned tomorrow, or even five minutes from now.
If that is fine with your end users, then a SELECT * FROM myTable is the right solution for you. But, if you absolutely need to have the data returned in a certain order, you should always implement an ORDER BY clause.
if you want to have the same database order in most cases if you have sorted by primary key it will be the same without ordering as you say:
here the id is the primary key, and if you can not use the primary key add an identity column and use it:
id name
1 elly
2 ahmad
3 joseph
4 omar
While trying to implement pagination from server side in postgres, i came across a point that while using limit and offset keywords you have to provide an ORDER BY clause on a unique column probably the primary key.
In my case i am using the UUID generation for Pkeys so I can't rely on a sequential order of increasing keys. ORDER BY pkey DESC - might not result in newer rows on top always.
So i resorted to using Created Date column - timestamp column which should be unique.
But my question comes what if the UI client wants to sort by some other column? in the event that it might not always be a unique column i resort to ORDER BY user_column, created_dt DESC so as to maintain predictable results for postgres pagination.
is this the right approach? i am not sure if i am going the right way. please advise.
I talked about this exact problem on an old blog post (in the context of using an ORM):
One last note about using sorting and paging in conjunction. A query
that implements paging can have odd results if the ORDER BY clause
does not include a field that represents an empirical sequence in the
data; sort order is not guaranteed beyond what is explicitly specified
in the ORDER BY clause in most (maybe all) database engines. An
example: if you have 100 orders that all occurred on the exact same
date, and you ask for the first page of this data sorted by this date,
then ask for the second page of data sorted the same way, it is
entirely possible that you will get some of the data duplicated across
both pages. So depending on the query and the distribution of data
that is “sortable,” it can be a good practice to always include a
unique field (like a primary key) as the final field in a sort clause
if you are implementing paging.
http://psandler.wordpress.com/2009/11/20/dynamic-search-objects-part-5sorting/
The strategy of using a column that uniquely identifies a record as pkey or insertion_date may not be possible in some cases.
I have an application where the user sets up his own grid query then it can simply put any column from multiple tables and perhaps none is a unique identifier.
In a case that can be useful you use rownum. You simply select the rownum and use his sort in over function. It would be something like:
select col1, col2, col3, row_number() over(order by col3) from tableX order by col3
It's important that over(order by *) match with order by *. Thus your paging will have consistent results every time.