Viewing 15 posts - 50,251 through 50,265 (of 59,099 total)
Sarcasm forgiven... I know you just can't help it 😉
I absolutely agree that it will be mostly as static table and it will likely never be needed. But...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 28, 2008 at 6:29 am
What kinds of functions?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 28, 2008 at 5:59 am
... and how much the company wants to "keep". No one is indispensible.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 28, 2008 at 5:57 am
Heh... no, the approach is not wrong... it's exactly what I suggested earlier. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
May 28, 2008 at 5:55 am
CrazyMan (5/28/2008)
I dont have a execution plan , but the table index structure is as below
IX_OQa_Binonclustered, stats no recompute located on PRIMARYBi
IX_OQa_Blo_Binonclustered, stats no recompute...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 28, 2008 at 5:51 am
1030 columns... that's a bit wide. I'm thinking that I'd divide the columns into logical groups and do a little horizontal partitioning with some decent indexing. Might even...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 27, 2008 at 10:53 pm
Oh yeah... almost forgot. Each daily database has it's own summary table. All of the days for each month are collect my a view for each month. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 27, 2008 at 10:33 pm
CrazyMan (5/27/2008)
yes jeff, its the Ph column
I was wrong about the databases at work... although they return all of the information for a given customer a full year back in...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 27, 2008 at 10:27 pm
Sure... Barry is on the right track. Try that.
I guess I don't need to tell you that the column information stored in the NTEXT column should really be normalized...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 27, 2008 at 9:30 pm
It could be something as simple as a really lousy conference phone.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 27, 2008 at 9:21 pm
I gotta ask... why is the data stored this way? It's mostly "death by SQL" and now you want to compound the problem by converting it to the equivelent...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 27, 2008 at 9:18 pm
Think about it... the skinny table is an "EAV" (Entity, Attribute, Value)... a cross tab Select is all that is needed as the source of the update. Would be...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 27, 2008 at 9:14 pm
You're right... not enough sleep...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 27, 2008 at 8:41 pm
achaudhr (5/12/2008)
One example of the query I am using on the view is:
select BibNumber from [vw_TypesOnlinePeriodicalsJoin]
where TiQueryValue...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 27, 2008 at 7:59 pm
Thanks for the feedback... 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
May 27, 2008 at 7:43 pm
Viewing 15 posts - 50,251 through 50,265 (of 59,099 total)