В PHP memory_get_peak_usage(), memory_get_usage() - узнаете сколько памяти жрет скрипт.
И параметр memory_limit устанавливает ограничения на потребление памяти. Можно поставить нужное значение для каких нибудь отдельных особо жручих скриптов. Можно динамически менять через ini_set()
Если кратко, то делаете так
START TRANSACTION;
INSERT ...;
INSERT ...;
...
INSERT ...;
COMMIT;
При этом пачка инсертов выполнится за один раз целиком, или не выполнется вообще ничего (ибо атомарность).
Идея транзакции в том, что она НЕ может выполниться частично. Она выполнится или целиком, или вообще не выполнится.
Ну а в данном случае, ее побочный эффект, то что операции в рамках одной транзации могут выполниться с меньшими накладными расходами, чем если их выполнять по очереди.
Вовсе не обязательно все команды делать за один вызов, главное в рамках одного соединения с БД.
Ну а ради теории, читайте мануал.
А вы посмотрите, сколько памяти в пике кушает PHP при обработке 1000 тестовых записей. И сразу поймете, сколько вам надо памяти для полноценной обработки.
Не устранить, а гарантированно поймать. Ведь не считается грехом запихивать участок кода в try-catch.
В приведенном примере, хоть формально и выполняется подавление, но на практике ошибка обрабатывается путем возврата значения null. Последующий код, разумеется должен быть расcчитан на значение null.
Может и 3.14здец, но достаточно типично, при сабмите сложных форм с табличными, списочными и вложенными под-формами. К тому же доверять корректности пришедшей структуре нельзя.
Мне привели упрощенные способы типа:
$v = isset($arr['a']['b']['c']) ? $arr['a']['b']['c'] : null;
Но, все равно, здесь нужно будет повторить выражение $arr['a']['b']['c'] дважды. Сначала для проверки на наличие элемента, а потом для доступа. И в приведенном примере выражение очень простое. А может быть что то мудреное, типа:
$arr[$tables[$t]['name']]['rows'][$r]['cols'][$c]['format']['borders']['top']
Даже в вашем примере, нужно будет повторить выражение $arr['a']['b']['c'] дважды. Сначала для проверки на наличие элемента, а потом для доступа. И в приведенном примере выражение очень простое. А может быть что то мудреное, типа:
$arr[$tables[$t]['name']]['rows'][$r]['cols'][$c]['format']['borders']['top']
А разве я там смогу делать индексированные запросы XML-документов по аттрибутам и значениям элементов? Ну типа "найти все документы в которых упоминается компания AAA, которая совершала покупки на сумму более чем NNN". Мне казалось что в PostgreSQL это просто разновидность BLOB полей.
Еще думал, что бы просто кэшировать такие объекты в виде сериализованного объекта, а при десериализации выполнять проверку, не пора ли обновить объекты в кэше. Но это какое то костыльное решение.
Стоит ли дополнительно покупать SSD чтобы установить на него ОС? (Все рабочие данные не влезут на SSD) Или это реально повлияет только на скорость загрузки ОС?
VirtualBox - Бесплатная, очень простая в использовании, не жрет ресурсы. Прекрасно работает и под Windows и под Linux, и соответственно прекрасно виртуализирует и Windows и Linux. Когда установите ОС, не забудьте установить Add-on-ы, чтобы был общий буфер обемена, общие диски между операционками итп
Такие решения вполне приемлемы, если есть гарантия что в таблицах не будет большого количества записей. Иногда лучше хранить список ID-шников через запятую, чем плодить таблицы связи многие-ко-многим.
Ну а в институте и на курсах конечно учат максимальной нормализации реляционных данных. А вот в реальной жизни имеет место и осмысленная денормализация.