Yes. But you will most likely have to redesign (normalize) your database so that it qualifies for 4NF, fourth normal form. Wether you have to do that depends on what those field names actually represent / mean. But if you cannot explicitly refer to each of them, I'm rather certain that you need to normalize your schema.
SQL was never designed to handle the query you try to formulate using the structure you have. First recommended stop is http://en.wikipedia.org/wiki/Database_normalization. Once you understand the purpose of normal forms, things will hopefully become more clear.
But in short, if you do not structure your data properly - specific to whatever task is at hand - you will not be able to manipulate it efficiently.
All of those response_q-whatevers should most likely be in a related table. I.e. another table, which relates to rows in the first table by some kind of key, most commonly the primary key.
Simple example, underline means primary key.
(possibly) OK: table person (id, first_name, last_name, home_phone, work_phone)
First off, you're not likely to ask "How can I retrieve all columns that end with "_name", because you know why and when you want a first name, and same goes for last name. They are not simply enumerations names of unspecified type.
Having two phone numbers in the table may be ok. But only as long as they are both distinct entities that represent different things (that are not interchangeable)
Not ok: person (id, name, phone1, phone2)
What is phone 1? What is phone 2? How do they differ. If they don't, they should not be columns in this table, but rows in a related table
person (id, name)
phone (person_id, phone) - i.e. the primary key consists is compound and consists of (person_id, phone)
Phone numbers will relate to entries in the person table by the person_id. It will exist only once (per id) in the person table, but each person may have multiple entries with this id, one per phone number.
It is common, but not necessary to introduce a new primary key, an auto incremented value which has no other purpose than identifying these phone numbers. It sometimes makes things easier, but it is by no means necessary. It would then look like this
phone (id, person_id, phone)
But you should then also add a unique index on (person_id, phone) because it makes no sense to allow storing the same phone number several times for one specific person.
When you do have this structure, you can easily retrieve all phone numbers for a given person, or for any person for that matter.
SELECT phone
FROM person p
INNER JOIN phone ph ON p.id = ph.person_id
WHERE name='jack'
This would find all people named 'jack', join those together with their corresponding entires in the phone table (by matching entries on the person.id vs phone.person_id fields) and show those phone numbers.
Also note that there is no longer an inherent limit to the amount of phone numbers you can store for one person. You may create such a limit in your calling code or in stored procedures. But you will not have to change the design of the database to accomodate another phone number.
