Today, I was caught a little off-guard by a question regarding the USE directive in SQL. While, it stumped me, it did give me pause to think. First and foremost, it occurred to me that part of the reason that I was caught off-guard was because, in the past, I’ve been advised to stay away from USE or similar directives in any language for a variety of reasons. For example, in languages like Ada, a use directive is a perfect way to completely clobber a namespace. Regarding the usage of JavaScript’s equivalent with operator, guru Douglas Crockford has dire warnings about actually writing programs which use it. Note, that the using directive from C#, is equivalent to an import in other languages (Python, Java) or even a require (Lisp, Ruby). The perils of clobbering namespaces for the sake of convenience in any language are well know. Now, in some languages, a use directive is not always the culprit when namespaces get clobbered. Languages which also have an as clause can be dangerous as well because they obscure the true origin or name of a given object. Part of the reason is that using USE or one of it’s friends is dangerous due to the fact that programmers risk forgetting that they used it. This kind of error is not restricted to the USE statement, however. For example, in Lisp, global variables are typically enclosed in asterisks by convention. So what, right? Well, early on in Practical Common Lisp, Peter Seibel points out that redirecting something like *standard-output* to point to another source, it would be all too easy to forget to put it back! Just like it’s easy to screw up redirection by forgetting to put it back, USE in most languages makes it quite easy to make trivial mistakes. Now, I am not suggesting that these examples are directly equivalent. I am, however, making the point that, in this day and age, we are well aware of how easy it is to make careless mistakes and USE directives only make it easier. Say we have an example instance of an SQL server and there are a couple of databases in there. We want to work with two of them (called panda and bamboo) each but we’ve got quite a lot to do with one. For an example such as this, databases like MySQL, provide USE only to be compatible with Sybase and even then only as a utility function. In any case, we’re going back to the example. We’re at the prompt and we’re going to work with with our first database, panda. So to save ourselves trouble, we go forth with a USE panda; and then go about our business. Then, we’re ready to go ahead and delete a whole bunch of records from bamboo so we run our DELETE * FROM trees; and all should be well, right? WRONG! We forgot to switch to the right database by using USE bamboo; so now we’re in trouble. While this is a simplistic example, the world would be hard-pressed to find a competent programmer who’s never been tripped up by the most simple of errors. It is for this reason that I am wary of USE and it’s friends. Unless there is a very good reason to USE USE, I suggest that programmers be very careful AS well AS when we USE AS. Together, they can be a tricky combo.