Автор пришел не с этим, а с "Но что-то мне подсказывает, что данную задачу можно решить куда проще и наверняка она уже давно решена"Ага. И читаем мой первый ответ который говорит что идею написать на пыхе демон с воркерами надо положить в мусорное ведро потому что делать это на пыхе будет иметь гемморой не сопоставимый с ожиданием задачи в какой нибудь очереди. И тут в теме появились вы и начали бороться с пхпфобией.
Сравнить можно вообще что угодно, главное какие выводы сделать.
Вообще не бомбит, прочтите мою цитату выше, в 3ий раз повторенную. Никаких претензий. А вот чего вы распаляетесь мне даже интересно?
<?php
// Show all information, defaults to INFO_ALL
phpinfo();Читал, только вот автор и пришел с тем
Читаем, что писал выше: "Не вопрос, если подразумевалась, что такой функционал сам по себе тяжелый. Хотя, сравнивать массив и ассоциативный массив только по памяти, как-то странно, это разные структуры данных. Тогда уж сравнивайте обычные массивы".
Никогда не спорьте с дураками, они стащат вас на свой уровень и задавят опытом.
К сантехнику прикрепили практиканта. Вызывают на выезд. Приезжают. Канализационный люк. Из него течет дерьмо. Сантехник подходит к люку и ныряет.
Через минуту выныривает, кричит:
- Ключ на 19.
Снова ныряет. Через полминуты выныривает:
- Прокладку No.6.
Опять ныряет. Выныривает:
- Ключ на 26.
Ныряет. Через минуту выныривает. Выходит, отряхивается и закуривает. Сел, отдышался и говорит практиканту:
- Вот так!.. Учись, студент! А то так и будешь всю жизнь ключи подавать...
учитывая что в той теме упорно не читали что вам пишут, игнорировали собственно вопрос автора
"массив в пхп вещь тяжелая" подразумевает, что есть лучшие реализации вне пхп
Вот это тоже не верно. Вы НЕ понимаете как работает сервис, вот и всё.
Здесь можно ставить точку.
При ста попытках без "Idempotence-Key" будет создано 100 платежей, которые будут висеть в ЛК ЮКасса в статусе "Не оплачен". И только если 101 будет успешным, в аналитике будет 101 платеж.
Вопрос здесь был задан, т.к. до этого момента, номера договоров не хранились в БД сайта, за ненадобностью. Прежде чем писать код, я попросил сообщество поделиться опытом.
Александр Талалаев, чей ответ я отметил решением, дал конкретный ответ. Сразу. Понимаете?
Вы же втянули меня в такой блудняк.. но это было здорово). Уже в 10й раз говорю вам спасибо.В блудняк втянули себя вы. Если бы вы остановились бы и задумались банально на ПЕРВОМ вопросе, - то было бы 2 варианта продолжения. Вы бы поняли что имодентность и возня с сохранением вам не нужна, можно было бы без нее, либо вы описали такой контекст задачи что я бы понял что вам она нужна, и сразу бы предложил вариант генерации UUID на основе данных.
ключ идемпонентности (Idempotence-Key) и id платежа (payment_id) - это разные вещи. Вы чего?
Упростим просто для примера Idempotence-Key до номера договора.
Зачем, по вашему, создавать новый объект платежа, если данные неизменны?
Зачем API ЮКассы обеспечивает идемпонентность запросов в 100% случаев?
Напомню, что вы не сможете обратиться к API ЮКассы без ключа. Никак.
Это ведь не такси, зачем это им? По вашей логике, это функционал поверх необходимого.
Требование такое, чтобы по одному и тому же номеру договора, платеж может быть только один.
Это годами устоялось, клиент привык к такому поведению и осознанно не желает это менять.
Привык, т.к. основной метод приема платежей работает именно так, ЮКасса подключается как дополнительный, альтернативный способ.