Евгений Лернер, Вы пробовали ответить, но попытка откровенно провальная. Попробую помочь.
Вариант 1. При отключении сервера данные пусть пропадают. После запуска накопление начнется заново, с нуля.
Вариант 2. Данные не должны пропасть. Следует обеспечить их сохранение и загрузку при следующем запуске.
Выберите один из двух вариантов.
Вы вообще знаете как работает inmemory db?
Вот не поверите - знаю.
Но InMemory DB и MySQL не соотносятся никак. Вообще никак.
PS. Да, эмуляция возможна. Но производительность будет скорее всего ещё хуже.
В контексте вопроса с учётом показанного кода это неверное утверждение.
В MySQL есть SELECT INTO OUTFILE/DUMPFILE, и не так уж и сложно построить запрос, который сформирует требуемое представление данных для выгрузки.
Вы обязаны начать с выкладывания результата выполнения SHOW CREATE TABLE Products;
Сейчас в принципе непонятно, есть ли у ODKU вообще материал для работы...
Если СУБД - а самом деле MySQL, то в незнании его синтаксиса. UPDATE не допускает никакого FROM.
Ну а если СУБД другая - то в неумении присвоить вопросу правильный тег.
А какие соображения заставили не использовать очевидный вариант хранения этих данных в одной таблице и раскидать данные по двум отдельным таблицам? Такая схема, с какой стороны не зайди, и неудобна, и просто нелогична, так что основания должны быть весьма вескими. И для имеющих смысл предложений нам бы было неплохо их узнать.
Можно попробовать поступить вообще наоборот - держать таблицу рабочих дней - нумерованно/сортированную. Тогда "крайний" срок просто считается плюсованием длительности периода допустимой просрочки к дате планового завершения. А для связной цепочки - просто суммировать эти допустимые просрочки отдельных этапов. Правда, и тут будет проблема - в момент начала выполнения задачи придётся всё пересчитывать, если задача начата не в плановый день.
Кстати, таблица пронумерованных рабочих дней поможет и в случае, если поступать экстенсивно - просто считать в глубину дерево работ.
И да - в обоих случаях сроки начала и окончания хоть и вводятся как характеристики, но далее будут чисто справочными, а расчёты должны оперировать посчитанной на их основе длительностью в рабочих днях.
Потому что phpMyAdmin авторизует тем пользователем, который указан в его конфиге, вероятно... или это в настройках PHP, поверх которого он работает.
PS. Убедись, что для этого твоего юзера testDB есть дефолтная БД.
А зачем тебе это o.created? какой в нём великий смысл? ну есть у юзера три разных значения, вывести можно лишь одно - ну и какое? кстати, сортировать по нему тоже бессмысленно, и по той же причине.
Если, скажем, нужно последнее - так выводи MAX(o.created). Если любое, лишь бы было в таблице - ANY_VALUE(o.created).
А лучше вообще не выводи.
Дархан Камалиев, создать MyISAM таблицу со вторичным полем автоинкремента и получать оттуда автоинкремент, индивидуальный для каждого юзера. Руками либо триггером.
Нумерация - отдельный объект, а не составная часть текста. Да он ещё к тому же и динамический. Так что только итерационно для каждого нумерованного абзаца получать текущий номер нумерации и добавлять "вручную".
Вообще неплохо было бы указать, что за десять записей... вообще? на юзера? на УРЛ? что-то ещё?
А вообще 30 записей в минуту - это 50 тыс. в день. Для сервера БД объёмы вообще ни о чём... так что согласен с тем, что предлагает Дмитрий, очистки раз в день хватит за глаза.
Вариант 1. При отключении сервера данные пусть пропадают. После запуска накопление начнется заново, с нуля.
Вариант 2. Данные не должны пропасть. Следует обеспечить их сохранение и загрузку при следующем запуске.
Выберите один из двух вариантов.
Вот не поверите - знаю.
Но InMemory DB и MySQL не соотносятся никак. Вообще никак.
PS. Да, эмуляция возможна. Но производительность будет скорее всего ещё хуже.