From: esquel@sommarskog.se   
      
   migurus (migurus@yahoo.com) writes:   
   > I came across a situation where application builds a list of names by   
   > matching first three letters entered by user. The list of names does not   
   > have any duplicates  The query generated by app is   
   >   SELECT LAST_NAME   
   >   FROM NAME_LIST   
   >   WHERE LAST_NAME LIKE 'GRE%'   
   >   
   > The result set is coming back as   
   >   GREAGORS   
   >   GREEN   
   >   GREISS   
   >   
   > Now user selects one line and application should retrieve that line, The   
   > app generate the same query as in the 3 letter case above   
   >   SELECT LAST_NAME   
   >   FROM NAME_LIST   
   >   WHERE LAST_NAME LIKE 'GREEN%'   
   >   
   > I don't like the lazy programming, it should have been WHERE LAST_NAME =   
   > 'GREEN' in my view,  my guts feeling is that the access plan for LIKE   
   > clause might be inefficient comparing to the = clause.   
   > The example above is simplified. But in essence is LIKE less likely to   
   > produce a perfect plan comparing to =, or there is no justification to   
   > my rant.   
      
   I would execpt there is no difference of practical importance, although   
   may some measurable difference if you 200 processes all sending this LIKE   
   query.   
      
   But apart from that, I agree with you. If nothing else, assume that there   
   also is a GREENE in the list.   
      
      
      
   --   
   Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se   
      
   Links for SQL Server Books Online:   
   SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx   
   SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)