title: When is using INSERT IGNORE good practice?
body: <p>In the world I live in, building a solution that throws all the darts at a wall, and hopes some hit the bull's eye is a pretty poor solution methodology.</p>
  
  <p>So, my question arises, when is using <code>INSERT IGNORE</code> in a production system acceptable by convention?</p>
  
  <p>I have a situation that I'd like to write a <code>TRIGGER</code> (see <a href="https://stackoverflow.com/questions/17353080/">#17353080</a>) that searches for existing data, if it is not found, then it is <code>INSERTed</code>.  A suggestion was to use <code>INSERT IGNORE</code> and rely in <code>primary keying</code> of unique fields.</p>
  
  <p>So, I have a predicament:</p>
  
  <ol>
  <li>Do I use <code>INSERT IGNORE</code> and rely on <code>primary keying</code> the fields I'd like to keep unique, failing any INSERTs of repeated</li>
  <li>Do I repeatedly query the target table to check if the field values I'd like to keep unique are present, then <code>INSERT</code> if they are not?</li>
  </ol>
  
  <p>Since these questions are too fuzzy to ask in this specific medium, I'd like to understand when it is acceptable by convention to use INSERT IGNORE, and I can make my own judgement as to my specific case.</p>
  
  <p>Thanks,</p>
  
  <p>Matt</p>
  
  <p><em>Meta:</em></p>
  
  <p><em>I take it that since <code>conventions</code> is an existing tag described as:</em></p>
  
  <blockquote>
    <p>A generic tag covering any accepted method of doing things, which
    could include naming, spacing, coding, commenting, etc.</p>
  </blockquote>
  
  <p><em>that questions of this type are acceptable.</em></p>