Станислав Почепко: У меня под рукой есть таблица на 1 279 311. Если я делаю запрос с order by rand(), получаю ответ за 2,6с.
В таблице на 1 700 записей - 0,003с.
На маленьких таблицах нет выхлопа от использования доп. запроса.
На больших, доп. запрос выгруженный в массив отожрет много памяти.
Любой ввод от пользователей надо валидировать и фильтровать.
Мне кажется что сервер - это хорошее место в архитектуре, для этих задач.
Куда вы хотите эту логику вынести? Прямо перед БД поставить? А как вы будете её расширять, если что? Половина кода на сервере и еще половина прямо перед бд будет?
Я вижу, что задача у вас, повысить скорость. И я бы попробовал так сделать в формате proof-of-concept, чтобы посмотреть какой выхлоп получаем. И если вы так будете только запросы на чтение слать, то может и выйдет жизнеспособное решение.
Но персонально я, исходя из своего опыта фильтровал бы все. Пусть и за счет падения производительности. А на компромисс бы пошел, если скорость критична, а прирост 3-5 раз.
Наверное вопрос касался не теории, а прикладного ПО посредством которого можно зеркалировать БД в слейв, а потом переключить слейв в мастера, а старый мастер удалить.
Минус в том, что при поиске рецепта котрый покрывает ваши продукты в холодильнике, придется доставать все записи из таблицы. Или извращаться с Like%.
Это неправильно.
А если автоинкремент ушел далеко вперед за 10000, как мы получим нормальное распределение?