Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You can do it by in one query by stringing together the individual LIKEs with ORs:</p> <pre><code>SELECT * FROM tablename WHERE column LIKE 'M510%' OR column LIKE 'M615%' OR column LIKE 'M515%' OR column LIKE 'M612%'; </code></pre> <p>Just be aware that things like LIKE and per-row functions don't always scale that well. If your table is likely to grow large, you <em>may</em> want to consider adding another column to your table to store the first four characters of the field independently.</p> <p>This duplicates data but you can guarantee it stays consistent by using insert and update triggers. Then put an index on that new column and your queries become:</p> <pre><code>SELECT * FROM tablename WHERE newcolumn IN ('M510','M615','M515','M612'); </code></pre> <p>This moves the cost-of-calculation to the point where it's necessary (when the data changes), <em>not</em> every single time you read it. In fact, you could go even further and have your new column as a boolean indicating that it was one of the four special types (if that group of specials will change infrequently). Then the query would be an even faster:</p> <pre><code>SELECT * FROM tablename WHERE is_special = 1; </code></pre> <p>This tradeoff of storage requirement for speed is a useful trick for larger databases - generally, disk space is cheap, CPU grunt is precious, and data is read far more often than written. By moving the cost-of-calculation to the write stage, you amortise the cost across all the reads.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload