Такие записи не попадут в выборку. Если вам нужны только посты у которых есть post_id в z_postmeta и z_admitad_product_data (в обоих таблицах) вам вместо LEFT JOIN нужен INNER JOIN
То есть INNER JOIN вернет пересечение таблиц, LEFT JOIN вернет всю таблицу A (слева) и совпадение с таблицей B (правой), RIGHT JOIN соответственно наоборот
joost, ну я не знаю вашей БД. Я сделал на основе вами предоставленных запросов, будучи уверенным что у вас есть данные таблицы :) Может не в ту БД вставляете?
А чем вас не устраивают такие ресурсы как templatemonster или themeforest. Нашли что понравилось и скопировали себе. Там все на бутстрапах и структурировано.
joost, Во первых, вы так не переделаете, первый запрос у вас находит посты, которые не имеют вложений, судя по именам
смущает where z_postmeta.post_id IS NULL Разве ID может быть NULL?
Я бы попробовал переделать на:
SELECT z_admitad_product_data.* FROM z_admitad_product_data as apd LEFT JOIN z_postmeta as pm ON apd.post_id = pm.post_id WHERE pm.meta_key <> '_wp_attached_file'
Александр И, все верно, только работает не вкладка, а воркер. У вас нет объектов window и document, вы никого никуда не перенаправите, ничего лишнего не подгрузите. У вас просто есть event, по сути который может сменить состояние чего то. Но это то, что понял я. Я конечно могу в этом плане ошибаться, но политика браузеров всегда заключается в том, что вы не можете сделать ничего без ведома пользователя, в том числе и кросдоменные запросы/релиректы и прочее. Что мешает в вашем случае вместо CDN сформировать url для смены пароля/оплаты чего либо, отправки конфиденциальных данных, да тот же самый ддос организовать в фоне со всех юзеров что были на вашем сайте?
Александр И, вы не поняли что такое БЭМ и с чем его едят, а за код с ваших примеров "я бы уши то пооткрутил" ©
Александр И, не вводите народ в заблуждение. Это штука замена более старым апи кэширование, направленное на работу в режиме офлайн. Я так понимаю, что для динамики и контента, требующего постоянного общения с сервером это никак не пойдет, вам в любом случае для кэша надо загрузить статику/страницу, если вы её не загрузили ранее и сервер лежит, то боюсь вы никак её уже и не загрузите. Эти API по большей части для SPA (для моделей на фронте работающих с localStorage)
Если проект без нагрузки/сложных вычислений, то и на KVM SSD Ferrum работает прекрасно — проверено. Ну а те кто растет, запросом в ТП, свободно переводят на старшие тарифы без каких то телодвижений со стороны проекта.---------- Добавлено 10.01.2017 в 19:22 ----------
Точно не меньше, а то не по феншую:
Это сравнивать теплое с мягким. Если с MySQL выкинуть реляции и сделать табличку вида key\value, где key уникальный индекс и выбирать только по key, то думаю по скорости она будет не сильно отставать, а если при этом взять что то что тредится, ту же Maria/PostgreSQL, или что то типо Oracle например, то я думаю тут даже NoSQL отдохнут в уголке. Только там, где в реляционной базе можно вытащить все одним запросом, в NoSQL придется собирать по крупицам. Тут дело архитектуры хранения самих данных, и сравнивать их надо по удобству пользования, а не по скорости. NoSQL это не серебрянная пуля, вроде бум прошел и время все расставило на свои места, каждому так сказать свои задачи.
seovisor,Не буду врать, но по моему индексы ограничены длинной, то есть varchar(255), так как длинна на один столбец для индекса не должна превышать 767 байт, 3 байта на utf8 итого 255*3 = 765
а зачем вам такие индексы там, в такой табличке?---------- Добавлено 10.01.2017 в 18:37 ----------
Индексами ограничивают выборку в большой таблице когда она не влазит вся в оперативку, по другому вы никак не оптимизируете. Если вам не достает скорости MySQL, переложите горячие данные в оперативку, например в memcached или redis
