Given that placeholders can only represent data values in query statement, a distinct statement must be prepared for each query that differs in items other than data values. If the differences from one query to the next involve the conditions used in the "where" clause, you just need to organize your code to provide for the various combinations of "where" conditions, and prepare a statement for each of those.

The OP is pretty vague about what you're trying to do (and some of the idioms in your SQL syntax are unfamiliar to me), but the following example might be relevant:

If you think that sort of approach is worth trying, you'll want to elaborate it to include some consideration of the values that are going to be passed along when these constructed queries are executed. At the very least, you want to avoid confusion about how many placeholder/parameter values get passed along with a given statement handle when it's executed. (If number of parameters passed on execution doesn't match the number of "?" placeholders, that can be fatal. -- UPDATE: and you want to make damn sure that you don't get confused about the ordering of parameters for a given statement. -- I updated the code snippet to avoid that sort of mistake; actually, I had to make a second update, to include "sort" in the for loop.)

Also, depending on how many times you have to build/prepare statements in your code, you may want to look at the "prepare_cached" function in DBI, so that you can avoid re-preparing a statement that was already used in a previous iteration. (You don't need to call "finish" on a statement handle until the process is completely done - but don't forget to do that before you disconnect.)

Another variation on my previous reply that might be relevant: I have a web app with a search page for probing a set of related tables, where the user can fill in search terms - it's a bilingual dictionary system, so search conditions can include things like headword spelling, pronunciation, part-of-speech, translated meaning, etc, in arbitrary combinations.

When the search form is submitted, the app loops over the fields that have been filled in by the user, and assembles two parallel arrays: "@where_clauses" and "@where_values". The first array is used to build the SQL statement (table names and join conditions are added as needed), and the second array is passed to the execute call for that statement. This way, the ordering of fields and placeholder values is assured.

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

I was hoping to use place holders, but I don't see any way for the place holders to also contain the text beyond the values. At best I can run a loop to build the string for all the LIKE bits, but it doesn't seem to offer a good gain.