Thanks for the help, folks.
I see how the reference tables (either for the dates or the possible
number of days in the range) would work -- pretty slick solutions. I
worry about tables like that being able to scale, though, should a user
choose a large date range... I think, instead, I'll use the
At 10:18 -0700 1/19/03, Jeff Donnici wrote:
> That would work, but it's not necessary. He should use a
LEFT JOIN, which will produce a row in the output for the
left table, whether or not any right table rows match it.
The syntax is in the MySQL manual.
I appreciate the pointer to LEFT JOI
Thanks, Harald. I'll experiment with this approach!
J
--
You need a helper table containing just the numbers 0..N, where N is
greater than the maximum number of days in the query above. For
example:
CREATE TABLE seq (val INT NOT NULL
> That would work, but it's not necessary. He should use a
> LEFT JOIN, which will produce a row in the output for the
> left table, whether or not any right table rows match it.
> The syntax is in the MySQL manual.
I appreciate the pointer to LEFT JOIN and have read through the site's
docume
I've got a table whose structure looks like this:
CREATE TABLE IF NOT EXISTS calc_hits
(id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
hit_date DATETIME NOT NULL,
PRIMARY KEY (id))
AUTO_INCREMENT = 1;
On a web site, a row gets inserted into this table
whenever a visitor uses a certain tool o
