Viewing 15 posts - 20,581 through 20,595 (of 22,233 total)
Personally, I would have two schema's within the same database. This will allow you to lock down one schema, but have referential integrity between the schemas where as you would...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 25, 2008 at 8:59 am
You know if you're getting different plans and different performance, you might have instances where one piece of data generates a plan that it can use and a seperate set...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 25, 2008 at 8:53 am
I think I'm losing track of the thread. Where are you with this? Have you tried changing the indexes in any of the ways that have been proposed? Have any...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 25, 2008 at 8:33 am
This is great! What a lot of fun, and really good information. I do like the DBA in traditional DBA garb doing the performance dance.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 25, 2008 at 6:51 am
Agreed on using JOIN statements instead of IN statements.
Do you really need the DISTINCT? That's usually added when the data is bad, the structure is bad, or the where clauses...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 25, 2008 at 6:34 am
Unless they're they're the only things in the field, then you could get away with:
SELECT...
FROM...
WHERE MyField = 'Project Managers Book'
OR MyField = 'The Project Book'
...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 25, 2008 at 6:01 am
There was a time when I was recommending using this code to eliminate dynamic SQL and still have a multi-valued search query:
SELECT....
FROM....
WHERE...
AND CASE WHEN @LocationTypeId...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 25, 2008 at 5:58 am
For literally the same index, COLA, COLB and COLA, COLB, no, I can't support that. I'd even say that's unsupportable if the first one was clustered and the second one...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 25, 2008 at 5:47 am
Have you looked at the execution plans for the those specific queries? Scans, hash joins, cursors, anything like that in evidence?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 25, 2008 at 5:39 am
We might just fit right in...
and
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 24, 2008 at 1:26 pm
{click-whoosh}{click-whossh} I am the master now, Andy {click-whoosh}
Anyway, I finished running the simple tests. Here's a question given the following table & query, what might happen?
CREATE TABLE [dbo].[users](
[LogonID] [nvarchar](20) NOT...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 24, 2008 at 1:16 pm
Funny you should say that. I'm stepping through writing up samples in C# using nHibernate as I type this (well, right after I type this and right before). So far,...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 24, 2008 at 11:47 am
Yep. You're in trouble now. I still haven't been able to get it fixed. A friend ripped out everything, including all references in the registry, and reinstalled 2005. He's running...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 24, 2008 at 11:08 am
Oh, then it's not a covering index. Try adding the date column. It will be then.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 24, 2008 at 11:05 am
I'm not sure if means anything in relation to LINQ and the other ORM products, but I've seen systems where the developers used ADO to automagically access the database. Small...
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 24, 2008 at 10:45 am
Viewing 15 posts - 20,581 through 20,595 (of 22,233 total)