SQL doesn't know that Frankfurt is an airport, John Doe a name or D-AIHK an arcraft
registration. So if we throw in a term like Lufthansa without additionally giving the hint that
this is an airline, SQL would search for matches in airports, photographer names, aircraft types
and so on which decouples system time and load to serve the request.
Questioned on a term like Chromodynamics, where would you look first
in the dictionary? Probably the index, under C then Ch and Chr to narrow your search.
SQL does the same (and yes, Google too), we work with indexes, as in real life!
Like millions of other databases we rely on SQL in order to serve requests as fast and accurately
as possible. There is however a burden we all share: SQL needs help in form of decent input to work
properly and not to waste resources.
Indexes begin with something!
UIO Quito [Mariscal Sucre], Ecuador
- starts with UIO (fast results, not causing needless load)
- contains Quito and Mariscal and Sucre (slow)
- ends with Ecuador (also slow, use only when not looking for UIO)
Tim Feise (photographer name)
- starts with Tim or Tim Fei (fast)
- ends with Feise (slow, starts with Tim Fei would be 10 times faster)
LTU International Airways
- starts with LTU (simple, quick, get it?)
- ends with Airways (makes no sense, right?)
Only if we choose "starts with" or "is exactly" SQL can show it's power. Choosing "contains"
will lead to a long request time as the system searches one by one through hundred thousands of records.
If you can use starts with then do it. The system will thank you by responding quickly.