Forum Replies Created

Viewing 15 posts - 16 through 30 (of 57 total)

  • RE: A Faster BETWEEN Dates

    happycat59 (11/3/2010)


    Not only is the original article of interest (and it is great to have someone prepared to write about their findings...thanks Terry)

    Does no one actually care the entire article...

  • RE: A Faster BETWEEN Dates

    Adam Machanic (11/2/2010)


    david.avraamides (11/1/2010)


    I would consider using a sentinel date such as the maximum T-SQL datetime (9999-12-31) for two reasons: 1) your queries become simpler since you don't always need...

  • RE: A Faster BETWEEN Dates

    Paul Muharsky-474732 (11/1/2010)


    Absolutely would put a rediculous enddate in place. NULL values are stored as a bitmap at the leaf level of on index (clustered or otherwise), but are...

  • RE: A Faster BETWEEN Dates

    jpenniman (11/1/2010)


    Did you clear the buffers between tests? Using: dbcc dropcleanbuffers. If not, it would explain your "performance gain"

    His illusory performance gain is explained entirely by the fact...

  • RE: A Faster BETWEEN Dates

    UMG Developer (11/1/2010)


    You might as well make the query an INNER join so that it is more readable, you get the same results:

    Actually, that doesn't give the same results either....

  • RE: A Faster BETWEEN Dates

    david.avraamides (11/1/2010)


    I would consider using a sentinel date such as the maximum T-SQL datetime (9999-12-31) for two reasons: 1) your queries become simpler since you don't always need that "or...

  • RE: A Faster BETWEEN Dates

    Terry,

    Here's a short, simple script that shows your "improved" query doesn't yield the same results as the original. The first query returns 3 rows; the second only...

  • RE: A Faster BETWEEN Dates

    terrance.steadman (11/1/2010)


    Ok, some of you are complaining about the use of the LEFT JOIN. Please allow me to explain. When I am running some reports on the data,...

  • RE: A Faster BETWEEN Dates

    First of all, did you look at the query plans between the two approaches? Or flush caches?

    Secondly, why use a boolean flag when the below approach is...

  • RE: Do You Really Need Surrogate Keys? Part 1 – Concepts and Methods

    Robert Frasca (10/27/2010)


    When I'm data modeling, I don't consider existing tables in a schema to be "tables". I consider them to be "entities".

    When I'm standing in the...

  • RE: Do You Really Need Surrogate Keys? Part 1 – Concepts and Methods

    Robert Frasca (10/27/2010)


    Since when? With all due respect that's pretty much a nonsensical statement. What difference does it make whether it's a new schema or an existing one?...

  • RE: Do You Really Need Surrogate Keys? Part 1 – Concepts and Methods

    TheMOTU (10/26/2010)


    The default of having PK as a clustering one is a very BAD choice in most cases - because it creates Hot Spot on INSERT and table scan on...

  • RE: Do You Really Need Surrogate Keys? Part 1 – Concepts and Methods

    ta.bu.shi.da.yu (10/26/2010)


    Bingo. EBay's example is actually very interesting, and to my mind extremely sensible and yes, that is normalization. However, the example he gives is not an example of applying...

  • RE: Do You Really Need Surrogate Keys? Part 1 – Concepts and Methods

    Robert Frasca (10/26/2010)


    Tables are the product of normalization.

    True-- when starting from a clean slate. In practice, the word "normalization" has come to mean aligning an existing schema with the...

  • RE: Do You Really Need Surrogate Keys? Part 1 – Concepts and Methods

    I'll give a somewhat more realistic example. Say you have a chain of bookstores, that sell product from different publishers, and each specializing in one or more genres. ...

Viewing 15 posts - 16 through 30 (of 57 total)