Как запилить фичу и не выстрелить себе в ногу

[pawlo16]

Вот это вот

цену понадобится менять не только для категории и региона, а еще и для определенной модели авто или ещё по какому-либо признаку.

логически ни как не связано с

В общем, MySQL отпал как вариант, и выбор пал на MongoDB, которая бы обеспечила нам широчайшие возможности динамического масштабирования и умела работать с массивами данных, без которых правила были бы бесполезны.

Вообще не повод для NoSQL. В SQL задачи типа «поменять цену в зависимости от признака» решаются на раз при правильной схеме данных.
Для Nosql могут быть объективные причины, но вы не назвали не одной из них. Выбор mongodb не понятен.
Какие такие возможности масштабирования в вашем случае предоставляет mongodb, которых как вы считаете нет в postgresql?
«умела работать с массивами данных» — это что вообще?

[Tumenbayev]

«Умела работать с массивами данных» — это для поиска, то есть мы привели все данные в один вид и по нему можем искать данные в коллекции через mgo, строя запрос по типу: 'data.region':1, 'data.cat_id':2 и т.д.

По поводу noSQL, есть такой момент как сохранения правил, то есть, если мы хотим создать правило по типу: регион: Московская обл, город: Москва, категория: авто-легковые, а таблица наша, не имеет к примеру поле city, то это правило никак не записать, монго даёт эту возможность.

[rusticus]

Наверное об этом и нужно было написать в статье, я как человек не работавший с mongodb не понял причин без этого комментария.