CJRoman, Не были бы это программисты, можно было бы какой то KPI придумать. С программистами, наверное всё таки лучше аргументировано объяснить что это не тупое исполнилово, а что это на самом деле важно. Донесите мысль что 10 минут, потраченных на актуализацию документации сэкономят часы разборок и выяснений кто виноват.
Для начала оцените размер который займёт такой набор. Для только русского алфавита это будет 66^n. Со знаками препинания - 80^n. Где хранить такой объём собираетесь?
И полный перебор пароля - не лучший способ.
upd. Бегут, потому что все рассматривают её как альтернативу реляционной БД. Но это не так. Нужно просто уметь использовать плюсы разных технологий и компенсировать минусы. А иначе получится https://habrahabr.ru/post/231213/
sim3x, А на практике иногда ещё условия выборки надо задавать. В Mongo для этого даже индексы есть. И всё что я говорю - это исключительно практические подходы, которые использовались в живых проектах.
sim3x, Быстрее получить сформированный документ чем собирать его по 10 разным таблицам и проводить какие то дополнительные конвертации полей и обработки.
Максим Федоров, Adamos, Хм... Это интересно! Я далек от этой области (продажи вообще не моё, даже рядом не лежал), но стараюсь интересоваться. Спасибо.
hollanditkzn,
Допустим добавили вы к заказу позицию, или контактное лицо, или поменяли реквизиты -> записываете эту информацию в базу и генерируете документ заказа, который кладете в Mongo. То есть если кто то захочет просмотреть заказ или сформировать отчёт (любые операции, где нужно только чтение заказа, а не его изменение), то вы выбираете его из Mongo в виде готового документа, а не собираете информацию из дюжины таблиц БД.
SELECT * FROM `cars_parameters` WHERE `parameter_id`='".$param."' GROUP BY `car_id`;
И наличие $param в запросе наводит меня на мысль что вокруг запроса есть цикл по параметрам. А значит у вас выполняется не один запрос, а много запросов, каждый из которых возвращает запись, которую вы потом и выводите.
