На кредиты бизнес не открывают, разве что возможно нужны какие то обеспечительные средства на счету, но явно не на рекламу хостинга =))
Билинг это же простая штука, по сути любая CMS интернет магазина является биллингом, которую надо доработать напильником =)) разница только что пока 10 клиентов можно руками обрабатывать заказы, а когда не успеваешь можно подумать про автоматизацию. Но это с моей колокольни.
Но да, ТС, тут правильно советуют, в нишу лучше с опытом заходить, а если цель 20-40 т.р в месяц, то проще поискать пару-тройку клиентов на услугу администрирования, обычно саппорт одного сервера в среднем от 3к до 5к, 4-10 серверов (даже 1-2 клиентов) обеспечат нужную сумму и не надо заморачиваться с биллингами, панелями, СОРМ и прочими
У аспро есть файл стилей который не обновляется и специально сделан для расширение или переопределения
ТС хочет чтобы в его фильтре рядом со значением была цифра соответствующая товарам этому значению.
Например у него есть диваны и фильтр: Прямой, Угловой и ТС хочет чтобы у него было как Прямой (200), Угловой (120), вот ему надо как то получить 200 и 120, но судя по вопросам предполагаю, что ему что то готовое нужно
В целом все же я могу вам посоветовать лучше воспользоваться эластиком, там уже все это есть и работает очень быстро, либо если товаров не много можете воспользоваться облачным сервисом algolia, там есть бесплатный тариф
Так там описывается важность последовательности полей при создании составного индекса, а не при выборке по нему =)) Порядок при создании составного индекса влияет на эффективность и это да, но если честно я ни разу не замечал чтобы порядок колонок в запросе влиял на применение индекса, а миф этот почему то постоянно ходит, тогда бы мы прежде чем писать запрос шли бы смотрели как был создан составной индекс.
Я не про это, а про то, как вы строите фильтр без чисел, это же какие то характеристики товаров которые есть в этом разделе. Вот как вы их получаете, явно не через гет параметры, а вы делаете какие то манипуляции с БД
ну давайте тогда иначнем с алгоритма вашего фасета, как вы получаете агрегацию?
ну да. true и false примерно поровну. Индекс из одного поля, другие колонки в отборе не участвуют и индекс не содержит включенных полей для select"a примерно такого вида:
select field1, field2, ... where indexedfield = 0
И второй момент select count() с аналогичным отбором.
Откуда у меня такие сомнения? При отборе с результатом, скажем 50% строк, сервер сначала перебирает индексы для получения ПК, а потом ищет кластеризованный первичный индекс для получения остальных полей строки. Не дешевле ли сразу сканировать всю таблицу?
Я если честно немного не понимаю про что речь =))) Запрос (простой) может использовать только один индекс. В вашем случае если у вас 50% одно значение и 50% другое, то БД будет перебирать только пол таблицы, но это все еще очень дорого если таблица большая, если конечно у вас фильтр не по единственному этому полю, а то если поле одно то и перебирать он не будет. Скажем так, индекс отрезает от таблицы кусок по которому он будет делать поиск и чем больше этот кусок тем дольше будет поиск
не составной индекс булевый это типа одна колонка где 2 значения? Ну если в целом у вас там во всех строках одно значение то оно не даст буста
Это не совсем так, точнее это совсем не так =)) в каком бы порядке вы не составили индекс расположение в where полей индекса никак не влияет на его использование
Давайте тут уж по честному, если вы уперлись в производительность индексов (если мы подразумеваем что они используются корректно), то мне кажется тут пора писать своё хранилище, а весь проект уже давно на расте или си переписан =))
PS. И сколько смотрел докладов по хайлоаду, ни одна из топовых компаний не поднимала вопрос о том, в каком формате должен быть праймари кей и если с такой проблемой не столкнулись гиганты типа озона, авито и прочие ребята, то уж думаю местные владельцы проектов уж тем более в жизни не столкнутся чтоб задумываться об этом =))
