alex-1917

А всего-то надо было написать тег вопроса и сам вопрос в одну строчку и пульнуть в гугл...
mysql Как из объекта убрать повторы
https://www.google.ru/search?ie=UTF-8&hl=ru&q=mysq...

30к учеников -это немаленький такой городишко в 300-400к населения.
зачем вам бояться 3м записей, с вашим-то жирным бюджетом?)))

На SC тебя бы на ЙУХ послали бы сразу...
Надо выдавать еще и схему БД, т.е. чтобы те, кто имеет немного времени, могли бы соорудить тестовую БД и сымитировать запрос, коли ты так боишься отладку запустить в БД.
Но вот я имею до восьми вечера полчасика и таки собрал твою БД - НИ ХРЕНА ничо не тормозит!
Я даже нагенерил 450к строк в первой таблице и 500 строк во второй.
Тестировал на хостинг 30р в месяц
Очевидно, ты что-то умалчиваешь...

Таблица xxxxx_response не нужна!
Скриптом от платежной системы сразу меняется СТАТУС заказа.
Таблица одна - ЗАКАЗЫ. Она связана с таблицей ТОВАРЫ, ПОКУПАТЕЛИ и пожалуй хватит для вас)))

Ну а если по сути:
Все лучшие практики по созданию магазина в одиночку заканчиваются получением паспорта и началом настоящей взрослой жизни с девками, блекджеком и коньяком.

Вот тебе подсказка (см. скрин), правда, убраны цвета, с ними на порядок больше возни и в БД и при поиске.
Т.е. разный цвет - это разный товар.


С другой стороны, иногда и цвета надо включать в комбинацию, т.е. один товар - это комбинация размера и цвета. Это актуально, если поставщик (или основная масса твоих поставщиков) отгружаюттебе что-тотипа такого ассортимента - если присмотреться, там на одном артикуле висят и размеры и цвета. дебильно конечно, но иногда без вариков

SELECT * FROM table ORDER BY city, years
сначала сортировка по городу, при одинаковом городе - сортировка по возрасту
в вашем примере имхо бред, так как какая сортировка нужна, не ясно ХОТЬ УБЕЙ)))
азбука б***

Автор!
Быстрые запросы на вставку в БД нужны для приложений уровня эльдорадо, мвидео и т.д.
В данном текущем случае, очевидно, речь идет о БД уровня страница хомячка, поэтому - ЗАБЕЙ! Хомячки это одобряют.

Склеивание через джойны не поможет, у вас плоские запросы и должны работать мгновенно, профилируйте запросы по отдельности и смотрите, чо и как.
Как тут выше-ниже советуют - то на то и выходит, никакой оптимизации не будет! так как у вас результат в виде ID получается сугубо по результатам очередного запроса, то вся байда будет стоять и ждать - лучше, если эта байда будет ждать в приложении (PHP), нежели вся байда будет висеть в памяти MySQL в ожидании...
Задайте на SC, там уровень спецов ощутимо выше, в идеале если Mike ответит...

UPD. Кстати, почему для получения одного ID вы юзаете fetch_assoc?????))))

А почему плоского запроса боитесь???

SELECT g.step_id, g.name, cg.status, cg.date_added 
FROM oc_gamefication g, oc_customer_gamefication cg 
WHERE g.customer.id = 26854 AND g.id = cg.gamefication_id

Посмотрите баддипресс, там точно такие же стартовые данные, касаемо вашей псевдотаблицы - есть там и такой кусок, реализован не на 9, а на 4 таблицах!!))
Т.е. берете баддипресс, запускаете с демо-данными и выгружаете дамп БД в любой конструктор, далее тщательно и вдумчиво изучаете сформированную блок-схему.
Или поищите в гугле блок-схему оную, наверное, есть....
Баддипресс кароч. Это все, что надо знать про роли.

sypexgeo.net/ru/features

но вообще проблема высосана из пальца.
Всего в мире 2,7 млн городов, при этом статус города назначается местными органами. Например в Дании куча городов, в которых живут 250 чел.!!!)) Вы будете туда тоже продавать?)))
По сути если и продавать по всему миру (чо-то сомневаюсь что ТС это имел ввиду)))) ), то ориентир на город с 1млн чел. Таких и три сотни не наберется.
В упомянутом выше сервисе 83000 городов!!! sypexgeo.net/ru/stats

Блин, готовых же плагинов миллиард!!! например ULTIMATE TABLES и т.п.
Судя по всему, вы про класс wpdb не стали читать, ну так юзайте готовое...

если пользователь сам решает в какой валюте указывать цену на его товар?

заголовк вопроса ставит в тупик.. Я подумал сначала, что это про товар, который создает-редактирует сам пользователь...
У вас скорее всего более банальная банальщина - есть товары, есть курс валют и есть пользователь, который может только смотреть товар. Тогда все до безумия банально:
1. У товара цена - ОДНА. В какой-нибудь ОДНОЙ валюте.
2. Пользователь выбрал валюту - ему из БД отдаем цену в исходной валюте помноженную на выбранный пользователем курс валют. Курсы валют хранятся в БД. Выбранный пользователем курс можно хранить для каждого пользователя в его куках или локалсторадж...

Все хорошо, все просто:
1. подключаем любую либу для работы php с excel
2. парсим информацию из документа
3. загружаем фото (имя файла = артикул )
4. заполняем таблицу sql.

)))))

1. Устанавливаем www.mysqlfront.de
2. Скармливаем ваш ексель-пексель
3. Начинаем продавать ваши 800к товаров

p.s. насчет фото информации мало, поэтому то вы уж сами как-нибудь)))
почему мало? ну хотя бы потому, что 800к фото в одну папку совать - тупиковый путь. надо хотя бы по 1-3к в папку. Найдите любой менеджер файлов и раскидайте по папкам, самое простое - первые три символа из имени файла будут названием папки. Тут опять же возможны коллизии, так как будут повторы.. а может и не будут...
Хотя у вас уже полдела сделано (имя фото = артикул).
Эту расфасовку обязательно сделать перед заливкой, затем в архив и заливать через фтп, на хостинге файл распаковать.. Хотя 800к*50кб = 40Гб и это если по одному фото на товар! Вы там про какие 2Гб говорили?)))

На адекватном хостинге копия БД делается одной кнопочкой))))
На дешевом приходится выдумывать грабли, сидеть на Тостере и отнимать наше драгоценное время...))))

Ну а если без шуток, то юзай www.mysqlfront.de - шикарная вещь, льет 10-гигабайтные БД с полпинка, куча форматов для импорта-экспорта, конструктор запросов и т.д.
Единственный минус - что .de )))

$tmp="SELECT NAME, ID, IBLOCK_SECTION_ID FROM b_iblock_section where ACTIVE = 'Y' and IBLOCK_ID = 9 ORDER BY IBLOCK_SECTION_ID, NAME";
$arr = mysql_query($tmp);
while ($item = mysql_fetch_array($arr)){
	echo $item['NAME'];
}