THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |


You searched for the word(s):
Showing page 1 of 2 (18 total posts) < 1 second(s)
  • re: In defense of SELECT * in production code, in some limited cases?

    I'm with Rob F. on this one - if I were going to do this I'd put the * in the outer query and explicitly name the columns in the subquery. &nbsp;I like Jared's test, but I think I'd have to do more testing to be sure that the subquery was not returning more than it needed to the outer query (using different indexes, different combinations of ...
    Posted to Alexander Kuznetsov (Weblog) by Mike C on June 11, 2010
  • re: In defense of SELECT * in production code, in some limited cases?

    Have you tested whether the optimizer is smart enough to exclude columns from the inner query result that aren't used by the outer query? &nbsp;For instance, if you had a Column7 varchar(max) on the table but it wasn't used by the outer query.
    Posted to Alexander Kuznetsov (Weblog) by Mike C on June 5, 2010
  • re: SSIS – Delete all files except for the most recent one

    Todd - I created a similar package a while back -- FileInfo was very slow over the network for some reason. &nbsp;I found the Directory class methods worked much faster than DirectoryInfo and FileInfo. &nbsp;If you want to quickly modify Jorg's example, just modify it to use the FileInfo .CreationTime property (it's a System.DateTime property): ...
    Posted to Jorg Klein (Weblog) by Mike C on May 29, 2010
  • re: Five things SSIS should drop

    I agree the SCD wizard sucks, but it should be completely rewritten from scratch. &nbsp;Most SSIS folks I know run straight to a high-performance component like TableDifference to manage SCDs or use a staging table strategy with MERGE to avoid the pain of the SCD wizard.
    Posted to Jamie Thomson (Weblog) by Mike C on May 11, 2010
  • re: Debunking Kimball Effective Dates

    No problem. &nbsp;The thing people miss is that even in a denormalized DM, speed is a *secondary* consideration. &nbsp;It's easy to get fast results if you don't care how wrong they are. &nbsp;In every DM (at least the ones I've built) correct results are the *primary* consideration.
    Posted to Jamie Thomson (Weblog) by Mike C on February 21, 2010
  • re: Debunking Kimball Effective Dates

    @JaggedEdge - Don't be skurred. If GROUP BY skurrs you, then try a CTE with a windowing function (ROW_NUMBER) instead. Not sure why you'd find GROUP BY skurry. &nbsp;If something were to keep me up at night it would be the possibility of incorrect results, not set-based SQL syntax.
    Posted to Jamie Thomson (Weblog) by Mike C on February 21, 2010
  • re: Debunking Kimball Effective Dates

    Using Jamie's method of storing just a start date you can *accurately* infer the end dates. &nbsp;As has been pointed out already here, accurately enforcing end dates when you store the start and end dates is a lot tougher. &nbsp;Even if you want to store the start and end dates in the Kimball-style datamart, you would do well to store just the ...
    Posted to Jamie Thomson (Weblog) by Mike C on February 21, 2010
  • re: Decrypting : A question of morals, ethics, or both?

    This is a little OT, but I've been wondering why MS didn't include better encryption for database objects. &nbsp;SQL 2005 and 2008 have much better encryption capabilities than 2000 did. Simple insecure obfuscation seems to be a backwards-compatibility throwback, and a pretty useless one at that. &nbsp;With SQL 2008 and EKM you could theoretically ...
    Posted to Aaron Bertrand (Weblog) by Mike C on January 27, 2010
  • re: Follow Me

    Hallelujah! &nbsp; &quot;L'audace! &nbsp;L'audace! &nbsp;Tujours l'audace!&quot; -- Gen Patton
    Posted to Andy Leonard (Weblog) by Mike C on January 18, 2010
  • re: Invitation for T-SQL Tuesday #002: A Puzzling Situation

    Yeah I was so excited I hit the publish button too quick. &nbsp;Rather than just republish that one I went ahead and wrote up another one :)
    Posted to Old Blog of Adam Machanic (Weblog) by Mike C on January 12, 2010
1 2 Next >
Privacy Statement