I posted this tweet yesterday:
But my twitter stats will improve, so hurray! :-)
Seriously, though, it was a problematic tweet, partly because it was a piece of advice that only makes sense in a fairly narrow context, or as @brynlite pointed out:
As I was stretching this morning I realized: I should have written a post on my blog explaining the tweet, and then I could refer to that. Or as PL/SQL Challenge SQL Quizmaster@kibeha tweeted:
At the PL/SQL Challenge, we write quizzes. This happens on a regular, but not frequent basis. In other words, insertions into the QDB_QUESTIONS table (I could explain the difference in our data model between a "question" and a "quiz", but why bother, right?) do not resemble placing orders on Amazon.com.
A reviewer noted that with the QDB_QUESTIONS_SEQ defined with the usual cache of 20, question IDs (which we reference regularly in the reviewing and editing process, since there is no "name" per se for a question) would leap forward 20 at a time.
This gave a distorted view (not presented to our players) of quiz submissions. So he recommended switching to NOCACHE to minimize the gaps in question IDs.
I thought that was a fine and sensible idea, and so applied that change. Then, as is often the case, I used what I learned (or was reminded of) that day for my daily PL/SQL tweet.
Unfortunately, this particular "tip" is not appropriate for many (most, really) scenarios faced by developers when needing to generate unique ID numbers.
My apologies, and thanks to all for the corrective advice.
#314b #plsql Avoid gaps in sequence NEXTVALs: use NOCACHE option when creating or modifying sequence. #FrugalProgrammingIt was a great success social media-wise. Several Oracle technologists I admire greatly responded to it, and none favorably.
But my twitter stats will improve, so hurray! :-)
Seriously, though, it was a problematic tweet, partly because it was a piece of advice that only makes sense in a fairly narrow context, or as @brynlite pointed out:
I expect to repeat this often, Steven: don't advocate specific solutions until the requirements have been statedTo switch I rather snarkily replied:
Keep on saying it, I guess, Bryn, but I am not sure how the advice can apply in the world of Twitter.OK, fine, it wasn't my finest moment.
As I was stretching this morning I realized: I should have written a post on my blog explaining the tweet, and then I could refer to that. Or as PL/SQL Challenge SQL Quizmaster
Reason why tweets aren't well suited to teach - unless always tweeet links to blog / video / etcSo here we go:
At the PL/SQL Challenge, we write quizzes. This happens on a regular, but not frequent basis. In other words, insertions into the QDB_QUESTIONS table (I could explain the difference in our data model between a "question" and a "quiz", but why bother, right?) do not resemble placing orders on Amazon.com.
A reviewer noted that with the QDB_QUESTIONS_SEQ defined with the usual cache of 20, question IDs (which we reference regularly in the reviewing and editing process, since there is no "name" per se for a question) would leap forward 20 at a time.
This gave a distorted view (not presented to our players) of quiz submissions. So he recommended switching to NOCACHE to minimize the gaps in question IDs.
I thought that was a fine and sensible idea, and so applied that change. Then, as is often the case, I used what I learned (or was reminded of) that day for my daily PL/SQL tweet.
Unfortunately, this particular "tip" is not appropriate for many (most, really) scenarios faced by developers when needing to generate unique ID numbers.
My apologies, and thanks to all for the corrective advice.