Еще раз повторяю - проблема тут не в коде и не в том как автор делает запрос и вставку данных. Современные орм делают оптимизацию запросов лучше чем 90% разработчиков. Так же как и современный PHP достаточно быстр чтобы в таких операциях не быть узким местом.
Автор как раз таки использует один из вариантов решения, описанный разработчиками марии.
И что это изменит? Операция удаления такого количества строк всё ещё будет катастрофически долгой. Читать почему и как бороться тут - https://mariadb.com/kb/en/big-deletes/
Так может быть стоит разобраться, о чем идет речь, прежде чем писать своё мнение? Если так сделать, то окажется что и PHP и ORM тут вообще не при чем, и проблема как раз таки в том, как работает DELETE в MySql и его форках.
Господа дизлайкеры, прежде чем миносовать, рекомендую ознакомиться с постом, комментариями и вот этой ссылкой - https://mariadb.com/kb/en/big-deletes/, где написано, в чем заключается проблема и какие есть варианты решения.
Ну, вы ошибаетесь. Проблема из за лога транзакций при удалении, который пишется на диск. Почитайте остальные комментарии, там есть ссылка на сайт mariadb, где описывается эта проблема и как с ней бороться.
То что вы описали действительно увеличит скорость, но несущественно, относительно времени именно удаления, так что это экономия на спичках.
Учитывая, какое количество воды в книгах, то я бы поспорил. Например материал чистого кода вполне влезает в небольшой гитхаб репо с примерами и кратким обьяснением. Прочитывается за пол часа максимум, тогда как книгу нужно мучать несколько дней.
Звучит интересно и полезно! Хотелось бы потыкать) Freemium модель рассматривали? Кажется это неплохой вариант для подобных проектов. Мало кто готов платить деньги за штуку, которая мешает жить. А вот попробовать часть функций в ограниченном режиме, ощутить полезность, привыкнуть а потом уже перейти на платный вариант с доп. фичами мне кажется было бы проще для пользователя.
Вы бы поняли что не правы, если бы почитали пост и статью о которой я говорю https://mariadb.com/kb/en/big-deletes/
Еще раз повторяю - проблема тут не в коде и не в том как автор делает запрос и вставку данных. Современные орм делают оптимизацию запросов лучше чем 90% разработчиков. Так же как и современный PHP достаточно быстр чтобы в таких операциях не быть узким местом.
Автор как раз таки использует один из вариантов решения, описанный разработчиками марии.
https://mariadb.com/kb/en/big-deletes/
Ну вы почитайте и вопросы отпадут.
И что это изменит? Операция удаления такого количества строк всё ещё будет катастрофически долгой. Читать почему и как бороться тут - https://mariadb.com/kb/en/big-deletes/
Так может быть стоит разобраться, о чем идет речь, прежде чем писать своё мнение? Если так сделать, то окажется что и PHP и ORM тут вообще не при чем, и проблема как раз таки в том, как работает DELETE в MySql и его форках.
Господа дизлайкеры, прежде чем миносовать, рекомендую ознакомиться с постом, комментариями и вот этой ссылкой - https://mariadb.com/kb/en/big-deletes/, где написано, в чем заключается проблема и какие есть варианты решения.
Ну, вы ошибаетесь. Проблема из за лога транзакций при удалении, который пишется на диск. Почитайте остальные комментарии, там есть ссылка на сайт mariadb, где описывается эта проблема и как с ней бороться.
То что вы описали действительно увеличит скорость, но несущественно, относительно времени именно удаления, так что это экономия на спичках.
Странно что вы сами не догадались спросить - тесла то откуда у школьника.
Что вам пхп плохого сделал? Там боттлнек в удалении, где и так sql.
Потому что нужно еще и перенести сообщения в другую таблицу. И суть проблемы не изменится, операция удаления все еще будет боттлнеком.
При чем тут орм если боттлнек в SQL команде delete?
Читаю хабр года с 11 и уже тогда были подобные статьи) С другой стороны сейчас действительно стало сложнее по многим причинам.
Учитывая, какое количество воды в книгах, то я бы поспорил. Например материал чистого кода вполне влезает в небольшой гитхаб репо с примерами и кратким обьяснением. Прочитывается за пол часа максимум, тогда как книгу нужно мучать несколько дней.
ФиТбек вместо фидбек заслуживает отдельного минуса.
Если бы вы могли поправить текст, было бы здорово, ибо действительно может запутать.
Привет! А что за курс?
>ЗП при таком опыте это звоночек
Я бы наоборот сказал что автор слишком мало просит. 150к сейчас PHP разработчикам с 2 годами опыта платят. На Go как то побольше обычно.
Обычно в таких ситуациях берут больничный и отдыхают. Работать когда болеешь, да еще и ангиной ну очень некомфортно.
Не могу согласиться - работа разработчика в основном заключается в написании кода. За поддержку серверов отвечают другие люди - админы, девопсы.
Бывают же ситуации когда админа нет и сервер настраивает и поддерживает сам разработчик.
Звучит интересно и полезно! Хотелось бы потыкать)
Freemium модель рассматривали? Кажется это неплохой вариант для подобных проектов. Мало кто готов платить деньги за штуку, которая мешает жить. А вот попробовать часть функций в ограниченном режиме, ощутить полезность, привыкнуть а потом уже перейти на платный вариант с доп. фичами мне кажется было бы проще для пользователя.