Traversing in a loop weekly

Question

Hi,
I have a loop in which I would like to Select query on weekly basis starting from the last date, essentially traversing backwards week-by-week.  For example the table below represents the sample data for the query within loop, without WHERE
clause.  What I like to get from the first iteration, say 5 years length backwards from the last date, which is 16/05/2014.  In the second iteration the last date would be 08/05/2014, because that is the next backward week date and again for
5 years period from that date.
II am not proficient with SQL especially when it comes to dates and I am looking for the neat approach as I have thousands of iterations and performance is the important factor here.
Thanks

Answer 1

If you don't need a massive table (centuries and centuries of dates, just a few years), you could use master..spt_values, but keep in mind the table I used only goes up to 2048, and you'll have creates something with a built in limit that you might reach
someday. 
There's also nothing wrong with using this table to CREATE permanent versions of the tables either (so you use it once, at table creation time, rather than over and over).  You can also join it to itself a time or two and use row_number() for the numbering
too.  There are 100 creative ways to achieve the same thing, as you've seen.  As long as they aren't giving wrong sequence numbers, pick whichever method you like best and that meets your needs.  (Most of the many articles you'll find are probably
correct also).
Most to the point though, I suggest making a permanent version of the calendar table (numbers table too), because once a person starts using a Numbers table and a Calendar table, they find lots of other reasons to use them that they hadn't thought of before
(or that they were doing a different way), and since you now are in that category, make yours permanent too!
EDIT: Also, there's a little paradigm shift taking place too: a natural reaction to creating a calendar table or numbers table with way more numbers than you need at the moment, is that it's wasteful.  Ok, don't create one so massive that it needs its
own dedicated server (unless you really need it), but remember, as a relational database, handling data in sets is what it does best, so don't worry too much about creating one that seems too big.  The overall benefit to you and your organization (standardization),
combined with the most likely outcome (no discernible performance difference, possibly even faster than create plus use on the fly) says just make the permanent table.