Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have a generated query to MS SQL Server with complex where clause like this:
(t1.Column1 = SomeValue1 and t1.Column2 = SomeValue2)
OR (t1.Column1 = SomeValue3 and t1.Column2 = SomeValue4)
OR (t1.Column1 = SomeValue5 and t1.Column2 = SomeValue6)
...
(50 or more conditions like this)
Actually I have hierarchy list with 3 level depth. And I want to retrieve all 3rd level items with one query. So t1.Column1 here is the 1st parent, t1.Column2 is the 2nd parent. I have as many conditions in my WHERE clause, as many items are expanded on the 2nd level in list. There can be 1000 or more in the worst case.
I wonder if this can affect query performance. If so, is there any way to optimize this(table-value parameters, etc.)?
I've done some investigations with query plans and query compile time. Both look ok.
I'm going to go out on a limb here and answer; this answer will not be correct, because there isn't really a 'correct' answer given your level of detail. However, here's some possible tips (assuming that you NEED 1000 clauses in your query):
Try to keep the query consistent once created and executed. It will probably take some time to compile, but once compiled, the cache should do its job, unless you keep changing it (even if you just change the values around). Use bind variables if the values need to change.
Indexes - make sure both columns are indexed. Providing they both are and you always query both then you should be fine.
As a caveat to this - I'm not saying this is a good way to query a database, just that the two points above should help.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed last month.
Improve this question
So I am trying to improve my SQL, one topic that arose, does declaration help with performance or not so like for instance lets say you want to do a if else statement but you need to know if the count is higher than 0 for example right
SELECT #COUNTER = COUNT(ID) FROM tblSome WHERE NUMBER > TOTAL
IF(#COUNTER > 0)
OR would it be better than something like this
IF((SELECT #COUNTER = COUNT(ID) FROM tblSome WHERE NUMBER > TOTAL)>0)
I am just trying to minimize the time it takes, but also it would be nice to know
For now I cannot really find a difference with the small amounts of data I am using and I am not sure how to test it further or go test it to the next level
Use of variables can help or hinder performance dependent on the exact circumstances. There isn't a single rule.
In this case the use of the separate variable assignment step can be harmful.
It gives the optimiser no choice but to count all the rows as it doesn't look ahead to how you use that variable in future statements.
using an IF (SELECT COUNT(*) ...) > 0 allows the optimiser to see that it is true as long as the count is >=1 and can sometimes be optimised to an IF EXISTS (semi join) and stop reading after a single row.
But you are better off just writing it as EXISTS anyway rather than relying on that.
(The discussion on this internet archived blog post has more about the circumstances where this optimisation might happen)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
So this isn't a technical question, but rather questioning why a language is designed the way it is.
I've been learning SQL and one thing that's been bothering me greatly is how SQL asks you to name the column you want and THEN name the table you want to get it from. To me, it would make more sense that you refer to the parent body (which is the table) and THEN the column it has. But SQL seems to forces users to do it the other way around. Why?
I'm just curious as to why the language is designed this way.
SELECT column
FROM table
why not
FROM table
SELECT column
SQL tries to mimic English language to some extent, so that it feels natural to formulate the query.
In spoken English you would say something like "I want the names of the employees". You would not say "I want of the employees their names" or something like that.
But you are right, it might have been a good idea to have the query represent the order of execution. And "From the employee table I want the names" would not be so far off the mark :-)
SQL is a descriptive language, not a procedural language. It describes the result set being produced. And, you can think of that result set as a report, with column headers.
As such, the basic querying construct returns those column headers. The rest of the query describes how they are produced.
You may find this post useful. Starting with FROM is the most logical way to think about a query (Why would anyone write SELECT before knowing what to SELECT from?). However, SQL guidelines were designed as if your query were a command. Thus, you are commanding the system to SELECT the data for you, and the FROM further specifies that command.
Of course, the actual execution is distinct from the lexical and logical orders above.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have noticed that some people in database columns instead of for example id, user, addressare using something like h_id, e_user, f_address etc...
Is that some kind of security aspect? or maybe these are some shortcuts of words?
Its because there might be many id fields like user_id,category_id,that's why they use so that code is understandable.
And talking about columns name like f_address, they are just shortcut for say first address. It doesn't have anything to do with security but to increase the query readability use proper name to fields so that people can understand just by seeing column name what data it saves.
If there are fields like category_id and sub_category_id , it is understandable from the field name, but if i denote it using c_id and s_id, its hard to depict.
Well, 'User' is a security object in SQL Server, so using that is kind of scary. 'ID' and 'address' are way too generic to provide any semantics when used as attribute names.
If a purpose of design is to be maintainable and readable, then there some words that simply don't work.
Definitely not security related.
Some use it for readability or speed (you don't have to remember which table you gave a certain name->see following example) when writing queries.
i.e.
select a.name, b.name from table1 a join table2 b on a.id=b.id
Like this you have to remember that table1 is named a and table2 is named b etc.
But if you use tablename_field (which you can shorten by using only the first letter of the tablename). That way you never have duplicate fieldnames when creating join queries.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
Using Linq and EntityFramework we recently noticed, while testing our queries performances, that the use of Equal(=) operator to compare two integers takes around 800ms more than using a combination of GreaterThan(>) and LessThan(<) operators.
So basically, replacing itemID == paramID (Both being integers) by !(itemID > param ID || itemID < paramID) in our linq query makes the query faster by about 800ms consistently.
Anyone with a deep knowledge of SQL could explain this result to me?
If this was always faster SQL Server would do the rewrite for you. It does not so you can conclude that it is not always faster to do this. In fact it is a bad idea to do this rewrite in 99.999% of the cases.
The information given in the question (almost none) does not allow for further analysis.
Often people ask "why did this random change make my query faster". The answer is always: You accidentally triggered a better query plan. There is no system to it. Query plans can be unstable.
Psychic guess: The complex predicate forces a table scan (or makes it appear better) than using an index. That can sometimes be a good thing.
The first step would be to examine the generated sql. My guess is itemID is nullable and EntityFramework's default behaviour with nullable properties isn't the greatest. It will translate your query into something like: prop = value OR prop is null
If that is the case and you are using EF6, you can overide that behaviour by:
context.UseDatabaseNullSemantics = true;
Msdn
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
Just for reference I am using SQL Azure.
I noticed when I am trying to select data from a table based on a license plate and the state of that plate I get no results back if the state is "IN". I realize the word "IN" is reserved in SQL server; however, I am containing that within quotes in my query. I currently am in testing phase and have only one record in the table which has a lisence plate 287YGB and state IN.
If I write my query as follows I get nothing back.
SELECT MakeModel, CitizenID, VehicleID FROM tblVehicles WHERE tblVehicles.Lisence = '287YGB' AND tblVehicles.PlateState = 'IN'
If I write my query this way I get back my result. But this is not good enough.
SELECT MakeModel, CitizenID, VehicleID FROM tblVehicles WHERE tblVehicles.Lisence = '287YGB'
And finally, if I write my query this way I get the only row in the table.
SELECT MakeModel, CitizenID, VehicleID FROM tblVehicles
From these tests I can see that the last where parameter is causing the problem. I am assuming it is due to the fact that the word "IN" is reserved. Is there a way around this?
Reserved words usually only cause problems if you're using them as field names, and in that case you need to wrap them with brackets ("[]") to eliminate the problem. I will amost guarantee you that your PlateState has some garbage in it, so you need to either trim it first (LTRIM(RTRIM(PlateState)) = 'IN') or use Like '%IN%' instead, and this will return the results you expect.
try this
SELECT MakeModel, CitizenID, VehicleID FROM tblVehicles WHERE tblVehicles.Lisence = '287YGB' AND LTRIM(RTRIM(tblVehicles.PlateState)) = 'IN'