No problem, glad to help.
I noticed your comment in an earlier message about it seeming like a
workaround - I don't think it seems like a workaround at all.
Having a table with the possible values makes for a normal database
structure, and an approach that should keep you from having to modify
your application's SQL queries when someone decides to add contract
levels 6 through 10 and then later 11 and 12, for example.
I also wouldn't be concerned about performance using such a join - SQL
database servers are optimized for JOIN operations. They do them very
well. In your case I'd add a UNIQUE index on the contractlevel table,
more to guard against duplicate values than for performance, though it
certainly won't hurt performance.
Dan
Jay wrote:
Thank you Dan,
[...]
Otherwise it's just not possible to show
what's not there - in your case, think of this: how would MySQL know to
show 5 when there are no 5's, but not also show the count for every
other integer that's not there? (6, 7, 8, .. 1048576, 1048577, etc.)
[...]
Sure, easy to understand. I was thinking in a (1,2,3,4,5) list instead
of a table....
Thank you very much!
Jay
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
