Viewing 15 posts - 19,591 through 19,605 (of 22,226 total)
Different situations can cause either one to operate in a more optimal fashion.
Take the advice offered above. Do as proper a normalized design as you can to start. Then worry...
"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
September 15, 2008 at 8:27 am
msreddyn (9/15/2008)
Thanks Samrath ,thats what exactly i am looking for
Thank you very much
True, but use it the way Peso posted it.
"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
September 15, 2008 at 8:24 am
jay holovacs (9/15/2008)
I spent a number of years doing C++ (and loved it). TSQL and C# are very different tools and they solve very...
"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
September 15, 2008 at 7:46 am
One thing I'm aware of in our organization, and I think it's universal. Object oriented developers loathe TSQL. I've watched blood pressures visibly rise in meetings when the discussion comes...
"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
September 15, 2008 at 6:53 am
With only a little modification, you could use the code in this article:
http://www.sqlservercentral.com/articles/T-SQL/61461/%5B/url%5D
"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
September 15, 2008 at 6:29 am
Performance, assuming a proper data design, good indexes, well written queries, etc., is not an issue. Supporting hundreds of users running queries is supporting hundreds of users running queries. It...
"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
September 15, 2008 at 6:22 am
dmoldovan (9/12/2008)
However even if the applications share a SQL 2005 database you can still obtain some separation by placing the tables that are not common in different schemas.
True.
The problems...
"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
September 12, 2008 at 12:37 pm
Greg Charles (9/12/2008)
Grant,Out of curiosity, what problems have you had with cross-database ownership chaining?
Thanks
As long as those two databases live forever side-by-side... None.
As soon as you put them on...
"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
September 12, 2008 at 11:12 am
If the applications are not sharing substantial portions of data, different databases. Further, when you put them on different databases, don't allow cross-database queries. This is PAINFUL experience speaking.
"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
September 12, 2008 at 9:15 am
Oh wow! I wasn't aware of that. Sorry.
I haven't used the thing in years, or needed one. I guess that's a good thing.
"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
September 12, 2008 at 9:06 am
Another option, not necessarily a good one, is to add a version column to your PK and then only do inserts. You can then do one of two things. Insert...
"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
September 12, 2008 at 8:17 am
agatti (9/12/2008)
I want a great big dumpster and permission to throw whatever I want into it.
Or whoever...
"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
September 12, 2008 at 7:17 am
Red Gate also offers a log reading product. It works pretty well.
Gail's right though, while something like Red Gate's Log Explorer can help, auditing is a more intentional act...
"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
September 12, 2008 at 6:05 am
Just a side note, a hash match isn't necessarily a bad thing. It can be the best way to retrieve the data, depending on the data involved.
"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
September 12, 2008 at 6:03 am
Very little code to work with here, but have you looked at the ROW_NUMBER function in Books Online? I think that might help you do what you want.
If not, post...
"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
September 12, 2008 at 6:00 am
Viewing 15 posts - 19,591 through 19,605 (of 22,226 total)