Conventional usage is as follows:
... WHERE column-name LIKE "string"
Which, of course, selects rows where the values in the named column
match the string, which can, and usually does, have wildcards.
I have been using an inverted arrangement:
... WHERE "string" LIKE column-name
This allows the wildcards to be in the named column of the database.
What possible use could this be? It's hard to even get your head around it.
_*Example*_
I have an application that wants to apply changes to images, using the
fantastic ImageMagick program. Generally, these are simple size
reductions, and the same IM options can be used in broad categories --
with a few exceptions. I have two groups of images, named M.##.tif and
HG.##.tif. The IM options are to be different for the two categories, M
and HG, but the same within those categories -- with those few exceptions.
This could easily get out of hand and become a programming nightmare!
Here are the few SQL records (table:OPTIONS) that do this:
___key_ _priority_ _options_
M.23.% 0 options for image M.23
M.70.% 0 options for image M.70
HG.01.% 0 options for image HG.01
M.% 9 default options for category M
HG.% 9 default options for category HG
The search goes like this:
... WHERE "file-name" LIKE key ORDER BY priority LIMIT 1
I use the LIMIT 1 because each options field has the __complete__ set of
options for that case, but a different LIMIT (e.g. 2) could be used to
accommodate //additional/ /options for specific images. One can easily
see how this can also be extended to provide different options for other
image types, perhaps .jpg or .gif (M.%.GIF 8 options).
_*Other Applications*_
These are some other applications where I have used table column names
in the right argument of the LIKE operator.
_*Decision Tables*_
The condition stub is put into the database, and the "don't care"
entries are easily represented with LIKE wildcards. This doesn't save
having to make those tests, but the operation using SQL is simple to
implement.
_*Finite State Machine*_
The state transition tuples are represented in SQL, again with don't
care positions coded as LIKE wildcards.
--
Regards, Rod Dav4is / P.O. Box 118 / Hyde Park, NY 12538 / USA
Genealogy, et Cetera: http://freepages.rootsweb.com/~dav4is/
480 ancestral & collateral families, mostly 17°-19° century
New England & European roots. Total population: 117,600+
Annex: http://www.gencircles.com/users/dav4is/
email: [EMAIL PROTECTED]
Two roads diverged in a wood, and I... I took the one less traveled
by, and that has made all the difference.
-Robert Frost
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
