Sylvia, a well written article, and I can agree with you that using random aliases such as "a", "b", "c" is counterproductive. It's difficult to read and even more difficult to troubleshoot.

However, I have to disagree with another of your key ideas. Your suggestion that it's not worth aliasing table names simply to save a few keystrokes trivializes the amount of keystrokes one may save over a year, or even a week, by using sensible aliases.

Many SQL Developers (myself included) must maintain vendor applications over which we have no power to name objects. For example, one of my central applications has table names such as TPB105_CHARGE_DETAIL and TSM180_MST_COD_DTL. It is much easier and faster to type, and frankly easier to read, if I alias those table names using "charges" and "codes".