atis //

Опишу более комичную ситуацию. Почти «в тему», а кому-то может сберечь нервы.
Случай очень свежий. Отлаживаю вчера поиск на одном сайте. Установлено, что каждый поисковый запрос будет писаться в отдельную табличку, для статистики.
И наблюдаю странную картину: каждый запрос записывается трижды. Начал копать глубже и выяснил, что у меня вообще любой запрос выполняется 3 раза. Перерыл все конфиги апача и nginx, начал искать баги в конфигурашках движка сайта. Почти два часа убил на все это дело.
Результат: у меня в Хроме установлено два SEO-расширения, которые при загрузке любой страницы любого сайта как-то «передергивают» его дополнительно (не знаю зачем, не очень силён в тонкостях SEO).
Так что нужно быть осторожнее с расширениями в плане «неведомой происходящей фигни».

MongoDB хорош тем, что индексы у него уже отсортированы (а как отсортированы указываете при создании индекса)
P.S. как вариант посмотрите эти статьи, связанные с использованием поискового движка sphinx для поиска по значениям атрибутов:

Sphinx — не только для поиска!
Sphinx — не только для поиска! Моя история (Моя, в данном случае не означает моюисторию)

SQL дает встроенную валидацию структуры данных за счет нормальных форм, индексов и т.п.
Проверка корректности данных, которую дает SQL, — важна для разработки. Если её не будет, то придется писать руками эти проверки.

NoSQL дает возможность не возиться с маппингом, а сразу сохранять данные целиком объектами в базу.
Но это ещё не всё, NoSQL решения обладают предлагают средства для удобного маштабирования.
А так же средства по обработке всего этого маштабного хозяйства. В частности MapReduce.
Если у вас много данных или много запросов, и есть какой-то частный случай по данным, то NoSQL решение может быть полезным.
Если нет, то цитирую одного из разработчиков Apache Hadoop. На одном выступлении он изрек: «Если данных не очень много, то не выёживайтесь и используйте обычный SQL».

Что использовать в конечной ситуации — смотрите сами. Каждый вариант обладает своими достоинствами и недостатками. А ещё хорошо бы знать о недостатках и превращать их в достоинства.

Я делаю так:

$stmt = $db->prepare('INSERT INTO ids VALUES (0, :url)');

try {
   $db->beginTransaction();
   foreach ($ursl as $url) {
      $stmt->bindValue(':url', $url);
      $stmt->execute();
   }
   $db->commit();
} catch (PDOException $e) {
   $db->rollBack();
}

Вообще ваша задача как я понял это т.н. фасеточный поиск. en.wikipedia.org/wiki/Faceted_search
Когда передо мной стояла такая проблема я решал ее таким образом: есть таблица «товаров», в которой все товары.
Есть справочник «характеристик».
Есть таблица в которой идут тройки id товара — id характеристики из справочника — значение
Вся эта база индексируется сфинском. Далее делается примерно как описано в статье: habrahabr.ru/blogs/sphinx/64318/

Т.е. сначала например пользователь делает поисковый запрос «телефоны samsung». Одним запросом к базе данных мы выводим все телефоны, а используя группировку по id характеристики получаем все характеристики, которые возможны для этих товаров: т.е. например диагональ экрана, операционная система, ну и потом выбираем для каждой характеристики возможные значения, подходящие под запрос. Благодаря мульти-запросам такой поиск работает довольно быстро.

Потом соответственно пользователю предлагается выбрать характеристики из списка возможных. Ну и в общем то весь алгоритм. За разумное время реализуется, работает довольно быстро, с добавлением товаров в таблицу проблем нет.

Простые запросы (их процентов 80) орм упрощают конечно, а вот если надо нестандарт, то проще нативным sql сделать. Имхо конечно.