Adamos

Опенсурс и базарная разработка - это не выкармливание чужих идей.
Суть опенсурса - в привлечении к развитию твоего продукта людей, которые заинтересованы в его развитии.
Продукта, а не идеи. Развитии, а не написании с нуля.
"Гениальных идей" у любого студента полна голова, их тем больше, чем меньше реальных знаний.
Если ты не готов реализовать свои идеи сам - с какого перепуга их кто-то возьмется реализовать за тебя?

Так у вас не строка поиска, а строка зачистки от прочих символов. Добавьте в нее пробел и дефис, чтобы не удалять их (дефис - первым символом после ^), а потом уже в результате разбирайтесь с лишними пробелами и торчащими в конце-начале дефисами.

Если на сайте не лепили костыли, то формы должны появляться на страницах только при вызове компонента bitrix:form - вот его вызовы и ищите. Что-то вроде

$APPLICATION->IncludeComponent("bitrix:form.result.new", ".default", array(
                "WEB_FORM_ID" => "23",
                "IGNORE_CUSTOM_TEMPLATE" => "N",
                "USE_EXTENDED_ERRORS" => "N",
                "SEF_MODE" => "N",
                "SEF_FOLDER" => "",
                "CACHE_TYPE" => "A",
                "CACHE_TIME" => "3600",
                "LIST_URL" => "",
                "EDIT_URL" => "",
                "SUCCESS_URL" => "",
                "CHAIN_ITEM_TEXT" => "",
                "CHAIN_ITEM_LINK" => "",
                "VARIABLE_ALIASES" => array(
                    "WEB_FORM_ID" => "WEB_FORM_ID",
                    "RESULT_ID" => "RESULT_ID",
                )
            ),
            false
        );

Количество вариантов = (кол-во вариантов выбора в строке) в степени (кол-во строк).
Генерировать все возможные варианты - угрепаешься даже на небольших числах. Да никому это и не нужно.
Сгенерировать произвольный вариант - элементарно.
Берете массив длиной в кол-во строк, заполняете его случайными числами от 1 до кол-ва вариантов.
Потом в заполненных позициях заменяете это значение на номер выбранного ответа.
Вот и вся комбинаторика.

Стоит априори полагать, что вашу форму заполняет не пользователь на сайте, а китайский бот, никакого браузера не запускающий. А тупо отправляющий на ваш сервер заполненные чем ему угодно поля.
Соответственно, нельзя полагаться не только на то, что ваши скриптики чего-то там проверят, но даже на заданные вроде бы ограничения ввода типа того, что результат этого селекта может быть только цифрой. Рано или поздно он окажется строкой с SQL-инъекцией, например.

можно ли сделать join?

Можно. JOIN ON LIKE - вполне валидная конструкция. Тормозная только.

У вас под правильным заголовком дурацкий вопрос.
Вам либо нужны NULL-поля, либо нет.
Если нужны, то это теоретическое замедление все равно будет эффективнее большинства велосипедов, которыми вы сможете его заменить.
Если нет - зачем их использовать?

Хранилище данных - это в первую очередь инфраструктура.
Вопрос не в том, куда и как будут записаны файлы, а в том, как их сможет оперативно получить нужное количество пользователей.
Вы же рассматриваете самый низкий уровень хранения, который в дата-центрах давно решается более оптимальными способами, чем высосанное вами из пальца.

В вашем же примере единственное назначение класса фабрики - создание подклассов в одном методе.
А классы с фабричным методом умеют свой функционал ПЛЮС могут вернуть себя единообразным для всех них образом. Причем этот самый метод getMobile может заодно участвовать и в других методах того же класса, когда ему понадобилось создать клона, например.

Самая большая разница, на самом деле, будет даже не в коде этих классов или фабрики, а в том коде, который использует тот или иной паттерн извне. С фабрикой вы должны создавать всех наследников в одном месте и знать о них. С фабричным методом они могут приходить откуда угодно, и все, что вам нужно о них знать - это то, что они реализуют тот самый фабричный метод.

Паттерны - это же не о классах, а о взаимодействии между ними и уменьшении связности.

Это вообще не SQL-запрос. Это ваша фантазия на тему, как писать на SQL.
Пройдите какие-нибудь бесплатные курсы типа sql-ex.ru хотя бы.

А на февраль у вас, интересно, какие ограничения?
Не проще хранить реальную дату, а уже из нее брать MONTH() и DAYOFMONTH()?

Я клиентский js с горем пополам выучил.

На страничке скрипты можно писать тяп-ляп.
На сервере с таким подходом отстрелишь себе обе ноги.
Язык нужно знать, и знать серьезно.

И книгу не получается найти не старую

Флэнаган регулярно переиздается под новые стандарты языка.

Учебник по С++ от его создателя, насколько мне известно, не устарел и не имеет противопоказаний.
Под "компилятором" вы, скорее всего, имеете в виду IDE.
Во избежание дурных влияний посмотрите, например, на Code::Blocks.
Когда решите, что язык вам понятен и можно переходить к крутым программам с кнопочками - QtCreator.

Вам бы как-нибудь самому прикинуть, какой практический опыт вам хотелось бы иметь к окончанию вуза.
Проект этот можете вынести за скобки - он, скорее всего, все равно будет неудачным.
Важно, что вам придется изучить и преодолеть по ходу работы над ним.
Если у вас есть надежды и амбиции на серьезную работу с серверами - может, и Джава.
Если есть риск пристроиться в какие-нибудь Яндексы - Питон и Го.
Если, кроме местных веб-студий, особенной работы вам не светит - лучше Пых.
Если надежд никаких и после учебы пойдете в преподавание - можно попробовать С++ ;)

Вообще-то в Убунтах из коробки есть GoldenDict, позволяющий указать строку запроса в качестве словаря и работающий по двойному Ctrl-C в любой программе по умолчанию.
Вообще без бубнов и гамака...