Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Перед записью в базу надо проверить массив ассоциированных массивов, на уникальность но одному из ключей, например NUMBER.
Кто то наверняка это уже делал. Поделитесь опытом.
1 => array:8 [
"NUMBER" => "000883011HDUER"
"NUMBER2" => "000883011HCUER"
"WEIGHT" => "104900"
"VPE" => "1800"
"VIN" => "1"
"NL" => "08"
"TITLE" => "Sitz"
"TEILEART" => ""
]
Не в сети
collect($arr)->unique('NUMBER')
Не в сети
array_column($array, null, "NUMBER");
Не в сети
Есть два варианта, один работает но медленно:
Ссылка Как исключить повторяющиеся записи из массива?
function unique_multidim_array($array, $key) {
$temp_array = array();
$i = 0;
$key_array = array();
foreach($array as $val) {
if (!in_array($val[$key], $key_array)) {
$key_array[$i] = $val[$key];
$temp_array[$i] = $val;
}
$i++;
}
return $temp_array;
}
$details = unique_multidim_array($details,'id');
При массиве 500к , он замирает на десятки минут и не отвечает.
И еще вариент нашел :
Cсылка: How to make a unique associative array?
Работает 6 секунд.
$comboUserPosts = array_values(array_column($comboUserPosts, null, 'link'));
echo var_export($comboUserPosts, true);
Не в сети
При массиве 500к , он замирает на десятки минут и не отвечает.
@Proger_XP ты по прежнему считаешь, что обрабатывать дохуялионы записей в массиве на стороне PHP это нормально?
При этом всегда остаётся немаленькая вероятность что в результате ошибки записи в базе будут таки НЕуникальны.
Если решать задачу средствами SQL, то уникальность будет гарантирована, а тяжелые запросы будет выполнять оптимизированный на это сервер БД.
Все темы топикстартера, как я понимаю, относятся к одной и той же задаче https://laravel.ru/forum/viewtopic.php?id=4922
Изменено artoodetoo (01.12.2020 07:37:06)
There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
Не в сети
@Proger_XP ты по прежнему считаешь, что обрабатывать дохуялионы записей в массиве на стороне PHP это нормально?
Он ситуации зависит. Если их в БД изначально нет, то странно их вначале туда вставить, потом обработать, а потом извлечь (если памяти веб-сервера хватит, конечно). В PHP вполне быстрые стандартные функции, это все-таки Си; конечно, лучше не делать то же самое самим PHP, как человек тут выше делает в цикле.
При этом всегда остаётся немаленькая вероятность что в результате ошибки записи в базе будут таки НЕуникальны.
Для гарантий нужно использовать индексы (UNIQUE), вне зависимости от того, как ты обрабатываешь записи - через SQL или PHP, ибо два клиента могут одновременно выполнить один и тот же SQL и получить дубли.
Если решать задачу средствами SQL, то уникальность будет гарантирована, а тяжелые запросы будет выполнять оптимизированный на это сервер БД.
С этим я спорить не буду, так как все-таки очень зависит от ситуации. Вот еще два аргумента:
1. Чем "круче" SQL, тем меньше он переносим, а PHP - один на всех. При гипотетическом переносе проекта с MySQL на PgSQL (например) работы сильно прибавится. Да и отлаживать кучерявые SQL - так себе удовольствие.
2. PHP выполняется на стороне бекенда, а SQL - на стороне БД. В проекте вполне можно представить несколько независимых бекендов, но вот несколько независимых БД - с трудом (ибо это уже будут разные проекты). Так что решая задачу на стороне PHP ты нагружаешь (а то и блокируешь) только один бекенд, а не БД и все бекенды соответственно.
Не в сети