Это хорошие, практические советы не раз спасшие отнюдь не один реальный сайт:) При чем без покупки "крутого дорогого сервера" и без "тонкой дорогой работы по настройке ФС системным администратором".
Регулярки выполняются настолько быстро по сравнению с дисковыми операциями, что даже странно поднимать об этом вопрос.
Плюс ТС все равно надо думать о физическом разнесении этой файлопомойки по разным местам (хотя бы из соображений нагрузки/быстродействия от простого считывания файлов и возможности более легких бакапов). "Регулярки/кэширование/редиректы" (3,4 вариант) как раз позволят это сделать с минимумом вмешательством в архитектуру (раз уж это важно, хотя самое мудрое это изменить архитектуру), позволяя разнести это не только по папкам, а вообще по разным серверам.
Если свой сервер, то на крайний случай всегда есть brute force в виде создания ram диска и монтирования его куда положено. При Ваших текущих 100к файлах по 25кб будет достаточно 3гб. Будет летать.
Второй вариант, опять же при своем сервере, это ext4. Тут можем ошибаться, но нам впаривали что у нее нет такой проблемы с количеством файлов в каталоге, как у ext3. Опять же, можно сделать том в ней и примонтировать как надо.
Третий вариант, это все же решить на уровне хотя бы .htaccess и раскладывания файлов по каталогам. Никто не мешает a*.jpg редиректнуть на /home/img/a/, а b*.jpg редиректнуть на /home/images/b. Минимум вмешательства в архитектуру (по сути и не вмешательство вообще), но в результате разнесение файлов физически по разным местам.
Четвертый вариант, он вообще контекстно-зависим, но в принципе никто не мешает допилить хак, который урлы картинок отдаваемых пользователю с http://site.ru/images/a*.jpg будет переписывать на http://a.site.ru/images/a*.jpg например (по сути вариант 3, только на более высоком уровне), тогда Вы эти картинки можете вообще по разным независимым серверам раскидать.
При чем в 3 и 4 варианте можно практически полностью сохранить внутреннею архитектуру, если перед редиректом/сменой урла проверять наличие картинки на новом месте, а картинки в новое место перекладывать неспешно, по крону например. Для облегчения нагрузки результаты проверки наличия картинки в новом месте можно куда-то запоминать (подойдет крошечный мемори кэш вида "адрес картинки" - "реальное хранилово").
p.s.: пятый вариант: врячить ссд:)
Самое простое.
Смысл - вешается уникальный индекс, соответственно в таблице могут быть только уникальные пары ad_text/ad_headline. ignore - позволяет проигнорировать лишние дубли в "новой" таблице с индексом. потом индекс удаляется - остается только 1 запись.
Если хотите чисто на php решение, то все тоже достаточно просто. В общих чертах так
select distinct(id), ad_text, ad_headline from jos_adsmanager_ads group by ad_text,ad_headline - выбираете по одному уникальному ид из таблицы для каждой группы ad_text/ad_headline
потом в цикле делаете нечто вроде
$sql="delete from jos_adsmanager_ads where id<>'.$row['id'].' and ad_text='.mysql_real_escape_string($row['ad_text'].... ну и так далее.
То есть удаляете записи с тем же текстом и заголовком объявления, но имеющими другие ИД - то есть дублями.
Документально все оформляется через обычный стандартный debt.wmtransfer.com , точно так же как и при взятии кредита у кучи других кредитующих кредиторов.
Это всегда и у всех так по дебту. Несмотря на это - никаких проблем не возникает, по крайней мере если не превращать обязательство в чек (после чего взыскать уже можно только в оффлайне, да и чек вроде оформить нельзя пока кредит не просрочен). При чем в договоре все равно указывается правильная сумма, так что крайне вряд ли что это приведет к каким-то проблемам.
Если нет долгов по лимитам и бирже, то в общем на небольшие суммы вполне адекватный процент, если использовать хотя бы минимальный скоринг заемщиков. Из-за 100 баксов осознанно терять аттестат с бл 100 смысла особого нет никому. Любопытно было бы посмотреть какое предложение сервис сделает заемщику с долгом допустим 10,000 уже.
Плюс крупные кредитные сервисы нередко возвращают часть процентов при досрочном возврате, здесь такое вряд ли будет возможно.
Та же фигня. По проценту и сроку уже похоже на минималку, интересно возможно ли на автомате получить сумму больше.
Как безумный, дичайший, но вероятный вариант:)
Проверку переменной Вы производите как $work, а не как $_GET['work'] и при этом у Вас в опере зачем-то когда-то установлена печенька (cookie) с именем work и пустым значением. Поэтому когда php все пихает в глобальные, то согласно правилу GPC (get/post/cookie) - последний переменной в work оказывается $_COOKIE['work'].
В любом случае сделайте в скрипте print_r($_GET); и покажите результат здесь. Сомнительно что переменная правда не передается.
Если данные у Вас как Вы написали, т.е. 100,000 товаров и всего 6 свойств (исходя из структуры 2 таблицы), то даже все свойства не будут проблемой на Вашем конфиге. Особенно учитывая что больше половины свойств у Вас битовые. Размер таблицы будет крошечный и проблемы представлять не будет.
А если говорить в общем обычно юзер не может искать по абсолютно всем параметрам, в поисковую форму выводят ограниченное количество - вот по ним и делают поисковую таблицу.
По поводу всех остальных ситуаций абстрактно не ответить, нужно смотреть на статистику товаров, их типы, важность параметров и т.д..
в идеале что бы это случилось сразу после наводнения и сверху шлифануть ураганом и землятрясением, для полной реальности ситуации! А то че это они на экваторе дома на -40 не расчитывают, а?!
Хотите выбрать товар у которого будут 3 свойства с заданными значениями? Это вряд ли сработает, ведь where работает по строке. optionID у Вас не может быть 1 ... and 2... and 3 в одной строке
А если Вы поставите optionid=1 ... or optionid=2 ... , то сделаете выборку в которой будет хоть одно свойство, но не обязательно будут другие.
В принципе это решаемо подзапросами... но Вы все равно огребете проблему, когда захотите добавить в выборку запросы вида "цвет не красный".
И в целом этот вариант будет не только сложноватый, но и как следствие тормозной неслабо.
Второй вариант лучше и по скорости и по простоте, особенно если параметров не сильно много. Правда вместо bit лучше использовать enum или set (при чем set поможет упаковать даже много параметров, если они все околобитового значения).
А если во втором варианте в таблице Вы оставите только те значения по которым идет поиск (полный список параметров храня в таблице с первой структурой), то это будет самый шикарный - третий вариант.
p.s.: кстати известные тормоза битрикса не в последнюю очередь из-за использования "по умолчанию" первого варианта структуры, что они попытались исправить "инфоблоками 2.0", правда не особо удачно.
Вообще-то 4% в месяц, 432-то на 1800. Если забыть о том, что у ТС черт знает что на лимитах происходит (он же даже общий долг "стесняется" открыть), это по нижнему краю кредитования на бирже, почти фантастично, но все же реально.
Он просто сказал то, что всем остальным говорить лениво. Последний кто тщательно скрывал долги по дебту это был мхост, до него... да тоже такого же плана кадры были. Поздравляем Вас с "вступлением в клуб".
p.s.: более того, proweb.com.ua еще и в "непонимающего" играет. В ответ на фразу про долг по лимитам доверия, изображает что не понял о чем речь и отвечает про долг на бирже 😂
p.p.s.: и даже более того, упорствует в отрицании! в ответ на фразу про долг по лимитам доверия, изображает что не понял о чем речь и отвечает про открытые сейчас лимиты доверия, а не про долг
LEOnidUKG, у нас уже есть острое ощущение, что у Вас диски на сервере накрываются или типа того.
На нормальном сервере с теми настройками и данными что Вы привели - время запроса по 6.7 секунд - чисто фантастика и абсолютно не норма. Или может у Вас триггеры какие-то на этих таблицах висят там... Ради интереса сделали аналогичные выборки у себя на полудохлом вдс от хетзнера за 10 баксов, все запросы укладываются в 1 секунду, те что у Вас по 4-5 на выделенном крутом серваке.
