Это верно, но как тут как раз те ошибки, на которых очень полезно учиться. Как говорит пословица, за одного битого двух небитых дают. То, что понял на собственном опыте, в сто раз ценнее чем то, что ты делаешь потому что дядя сказал.
Мне не очень нравится, что ваша аргументация сводится к общим словам уровня RTFM и ссылке на статью, в которой запрос insert не упоминается ни разу. Если будете трудиться отвечать на этот комментарий, то большая просьба писать только конкретные схемы.
В итоге мне приходится самому от себя получать адекватный фидбек. Получается что да, мы можем, наверное, залочить на чтение не всю таблицу, а только записи данного пользователя, прочитать верхнюю строчку, посмотреть в РНР, не превысит ли новое списание лимит, и если нет - то добавить новую запись и разблокировать остальные. Параллельная вставка не сможет прочитать максимальный баланс, и будет ждать вставки, после которой прочтёт в РНР новый баланс и увидит, что выходит за рамки лимита. То есть опять же, ваше лишнее поле не нужно, кстати. "Необходимость" которого вы, в своей обычной манере, постулировали, но не аргументировали.
При этом "отсутствующая величина" в виде атомарного апдейта позволяет перенести контроль выхода за пределы лимита целиком на уровень базы данных, причём вообще без блокировок. И заодно даёт ваш любимый дополнительный карман.
В целом же мне кажется, что вы путаете транзакции с блокировками. И полагаете, что транзакция - это такая волшебная палочка, которая как-то там сама по себе решает все проблемы - достаточно просто сказать волшебное слово "транзакция". А меня интересует именно конкретика.
Хороший вариант, но это будет уже следующий этап, до которого автору надо дорасти. Он только-только ООП начал осваивать. Пусть велосипедит текущую версию - и в процессе как раз дозреет до использования фреймворков. А если сейчас его посадить на Лару, то получится просто очередная обезьяна за пишмашинкой.
Насколько я понимаю, под "обычной транзакцией" вы имеете в виду полную блокировку таблицы. Поскольку другого варианта залочить под вставку нет. И если сравнивать её с хранением баланса в отдельной таблице (и блокировкой только одной строки в этой таблице), то эта величина хоть и "отсутствующая" но куда более приемлемая в реальности.
@moderator ну действительно, неужели так сложно автоматизировать "информационную службу хабра", если она всё равно гонит машиный шлак? Сделайте кастомный фид, из которого робот будет по набору правил брать новости, переводить, и постить на Хабр.
Вы так ничего и не поняли. про старый говнокод писать вообще совсем не нужно. Если писать - то про свой нынешний. В котором, судя по всему, у вас там в полный ад. И вы бы получили в сто раз больше фидбека, показав реальный код, а не картинки.
Но вообще, судя по всему, вам не на хабр, а на Тостер (https://qna.habr.com/). Описывать свои идеи по улучшению и сразу получать фидбек на тему почему так делать не надо.
Это верно. Но это не единственное достоинство пхп. Внешняя многопоточность делает его гораздо более устойчивым к проблемам с переполнением памяти например. Элементарный деплой, который стал уже притчей во языцех. У меня здесь на Хабре был длинный спор с одним явистом, в результате которого выяснилось, что ему проще поправить хранимую процедуру в БД, чем редактировать запрос в коде и потом это всё деплоить. Мы очень долго не могли друг друга понять, это просто разные миры!
Погодите, а откуда там хоть один юнион, не говоря уже о "простыне"? Ведь ваш список тупо строится по таблице транзакций, которая и так есть у автора? Я могу неправильно понимать структуру таблиц автора, но пока я вижу только одну, из которой всё берётся простым запросом, без всяких юнионов
Извините, но это просто чушь какая-то. Судя по всему, в части инъекций там остался весь ламерский код из предыдущей версии, и вы мечетесь, пытаясь применить дебильные советы из интернета, как уменьшить урон, и в частности не давать право на вставку. Хотя этого давно никто не делает за полной бессмысленностью.
Бороться надо с инъекциями, а не с их последствиями.
Очень плохое решение. Достаточно в каждом поступлении/списании хранить еще поле остатка.
Очень смешной комментарий. Звучит как "очень плохо класть зажигалку в карман. Достаточно пришить ещё один". Вам не кажется, что "хранить еще и поле остатка" - это дополнительное действие, которое никак не подходит под формулировку "достаточно"? А достаточно как раз хранить только сами транзакции?
Другое дело, что с дополнительным полем можно будет реализовать атомарный апдейт и избежать двойных списаний без блокировки всей таблицы. Но тогда это должно быть поле в отдельной таблице с уникальным user_id. И делать транзакцию, где сначала идёт апдейт этой таблицы с условием, и роллбек если условие не выполнилось.
Во вторых, после подтверждения, прям перед update - простая проверка, записан там кто то или нет.
Непонятно, почему такую проверку нельзя было сделать и для INSERT. То есть вы, кажется, так и не поняли своё же решение, выставляя его так, что ключевым является избавление от инсерта, а не проверка перед записью.
Но главное, такая проверка не гарантирует перезаписи при одновременном сохранении формы. Но это пока не горит, а потом узнаете про борьбу с race condition поподробнее.
Статья вызывает смешанные чувства. С одной стороны, ещё года два назад такое сочинение пятиклассника "как я провёл этим летом" выпинали бы в чулан in no time. С другой - поляна настолько обезлюдела, что надо поддерживать и такие ростки.
Примерно то же самое относится и к оформлению. Вроде бы, статья про РНР, но в качестве иллюстраций... картинки интерфейса! Хотя куда логичнее было бы приводить примеры кода. Просто поставьте себя на моё место: я зашел в хаб РНР прочесть статью а почему-то рассматриваю картинки, которые вообще ничего не говорят о внутреннем устройстве системы.
Чисто для информации:
активная поддержка РНР 8.2 уже завершена. Если переписывать сейчас, то под 8.4. Хотя конечно там для вас разницы, пожалуй нету, но всё равно целевой версией надо ставить текущую.
Переписывать на PDO смысл сомннительный. Разница между PDO и mysqli минимальная. Единственное, принципиальное отличие - в mysqli нет именованных плейсхолдеров, вида :name, а только знаки вопроса. Если это для вас принципиально - то переписывайте конечно. Хотя я бы пока сосредоточился на более важных вещах. А потом уже при следующей итерации сразу перешел на какой-нибудь ОRM
Но если говорить в целом, то главное что вы довели этот проект до конца. Это самое важное. А опыт приложится.
Это совет из серии "Лучше быть здоровым и богатым, чем бедным, но больным". Давайте вы возьмёте на себя миссию объяснить заказчику, что затраты на проект надо помножить на два? А уже потом тот наймёт фронта, который расскажет автору как всё плохо.
Я очень хорошо читаю, что вы пишете. Ваши идеи сводятся к тому, что ПХП - язык для говносайтов, и надо было продолжать писать на нём говосайты, а не развивать язык, добавляя в него новую функциональность, и улучшая производительность. А энтерпрайз писать на других языках. Но религиозные суеверия и косность разработчиков зачем-то сделали из него язык энтерпрайз уровня.
Сам по себе ход вашей мысли понятен. Просто посылки, из которых вы исходите, довольно странные.
решения которые он пытается догонять существуют десятки лет
Давайте вы будете подкреплять свои красивые слова фактами? У вас очень красивая и стройная проповедь, но с примерами в ней туго. При том, что все языки развиваются примерно одинаково, и берут друг у друга лучшее. И написать "догоняющий" можно про вообще любой. Тот же C# появился, чтобы "догнать" РНР на его поле.
Мне кажется, ваша проблема в том, что вы не можете толком сформулировать свою мысль. И в итоге подтягиваете трескучие аргументы даже не под конкретный тезис, а под неясную идею. И в итоге доходите до того, что начинаете ставить языку в вину тот факт, что он развивается и становится лучше.
Заголовок: Эксперты пояснили, почему в базе данных системы социального обеспечения США есть пользователи с возрастом более 200 лет Текст: возраст человека может быть 150 лет и больше. Картинка в тексте: если дата не указана, то берётся 1875, что в 2025 даёт 150 лет.
Новостная служба Хабра такая служба. Сколько читаю - столько не перестаю удивляться, как можно писать новости, но никогда не читать их.
Я думаю что вы это не специально, но у вас получился довольно иезуитский текст. Вы намешали верные посылки с неверными выводами и прямыми передёргиваниями. Делая, в итоге, то же самое, в чем обвиняете разработчиков языка: подгоняя аргументы под вывод.
Про религию и инерцию - всё верно. Но это ещё не вся правда. Помимо "любимого инструмента" есть ещё "любимая кодовая база" и "любимая инфраструктура". И решение сразу перестаёт быть таким простым, как "взять подходящий инструмент".
"PHP подходит для написания простых сайтов" - верно. Однако это совсем не значит, что не подходит для непростых. Даже чисто логически вы не можете сделать такой вывод. А практически - попытки "из кожи вон лезть" на самом деле дали очень неплохой результат. В РНР современная поддержка ООП, наравне с другими языками. Симфони вдохновлялась Спрингом, а Лара - Рельсами. В итоге РНР - это как бы два языка: процедурный "уэйл роу = муэскуэль фетч эррей" по гайдам из ютубочки, и вполне себе энтерпрайз с гексагональной архитектурой, DDD, TDD и чёртом в ступе.
Собственно, как раз в идее "всё переписать" куда больше уж извините, юношеского максимализма, чем практичности. Переписать пхпшный монолит на пхп-микросервисы с диспетчером на го? Отличная идея. "Переписать всё" и клепать круды на расте? А не попахивает ли это вашим же "подгонять инструмент под задачу"? При том что энтерпрайз - это как раз круды, на стероидах. И там важна в первую очередь осмысленная архитектура, а не язык. Тем более что всё равно писать будем на фреймворке, а не на голом языке. А разницу в коде на Симфе на Яве вы не враз заметите. Только по долларам и сможете отличить.
Вам-вам. Статья, конечно, халтурная, но ваш предыдущий комментарий тоже так себе. Я, кстати, и сам часто сталкиваюсь с этим - в голове самому себе всё ясно, а когда напишешь, то получается ерунда. Особенно когда читаешь по диагонали, а думаешь о своём.
В статье не предлагается использовать КРНР в своих проектах. Там предлагается использовать в своих проектах РНР, для логистики или крипты например. А Вконтактик привешен действительно не пришей собаке хвост, как не очень понятный пример "развития экосистемы". Хотя этому примеру уже сто лет в обед, и сейчас как пример стоило бы приводить скорее JIT.
Это верно, но как тут как раз те ошибки, на которых очень полезно учиться. Как говорит пословица, за одного битого двух небитых дают. То, что понял на собственном опыте, в сто раз ценнее чем то, что ты делаешь потому что дядя сказал.
Мне не очень нравится, что ваша аргументация сводится к общим словам уровня RTFM и ссылке на статью, в которой запрос insert не упоминается ни разу. Если будете трудиться отвечать на этот комментарий, то большая просьба писать только конкретные схемы.
В итоге мне приходится самому от себя получать адекватный фидбек. Получается что да, мы можем, наверное, залочить на чтение не всю таблицу, а только записи данного пользователя, прочитать верхнюю строчку, посмотреть в РНР, не превысит ли новое списание лимит, и если нет - то добавить новую запись и разблокировать остальные. Параллельная вставка не сможет прочитать максимальный баланс, и будет ждать вставки, после которой прочтёт в РНР новый баланс и увидит, что выходит за рамки лимита. То есть опять же, ваше лишнее поле не нужно, кстати. "Необходимость" которого вы, в своей обычной манере, постулировали, но не аргументировали.
При этом "отсутствующая величина" в виде атомарного апдейта позволяет перенести контроль выхода за пределы лимита целиком на уровень базы данных, причём вообще без блокировок. И заодно даёт ваш любимый дополнительный карман.
В целом же мне кажется, что вы путаете транзакции с блокировками. И полагаете, что транзакция - это такая волшебная палочка, которая как-то там сама по себе решает все проблемы - достаточно просто сказать волшебное слово "транзакция". А меня интересует именно конкретика.
Хороший вариант, но это будет уже следующий этап, до которого автору надо дорасти. Он только-только ООП начал осваивать. Пусть велосипедит текущую версию - и в процессе как раз дозреет до использования фреймворков. А если сейчас его посадить на Лару, то получится просто очередная обезьяна за пишмашинкой.
Насколько я понимаю, под "обычной транзакцией" вы имеете в виду полную блокировку таблицы. Поскольку другого варианта залочить под вставку нет. И если сравнивать её с хранением баланса в отдельной таблице (и блокировкой только одной строки в этой таблице), то эта величина хоть и "отсутствующая" но куда более приемлемая в реальности.
@moderator ну действительно, неужели так сложно автоматизировать "информационную службу хабра", если она всё равно гонит машиный шлак? Сделайте кастомный фид, из которого робот будет по набору правил брать новости, переводить, и постить на Хабр.
Вы так ничего и не поняли. про старый говнокод писать вообще совсем не нужно. Если писать - то про свой нынешний. В котором, судя по всему, у вас там в полный ад. И вы бы получили в сто раз больше фидбека, показав реальный код, а не картинки.
Но вообще, судя по всему, вам не на хабр, а на Тостер (https://qna.habr.com/). Описывать свои идеи по улучшению и сразу получать фидбек на тему почему так делать не надо.
Это верно. Но это не единственное достоинство пхп. Внешняя многопоточность делает его гораздо более устойчивым к проблемам с переполнением памяти например. Элементарный деплой, который стал уже притчей во языцех. У меня здесь на Хабре был длинный спор с одним явистом, в результате которого выяснилось, что ему проще поправить хранимую процедуру в БД, чем редактировать запрос в коде и потом это всё деплоить. Мы очень долго не могли друг друга понять, это просто разные миры!
Погодите, а откуда там хоть один юнион, не говоря уже о "простыне"? Ведь ваш список тупо строится по таблице транзакций, которая и так есть у автора? Я могу неправильно понимать структуру таблиц автора, но пока я вижу только одну, из которой всё берётся простым запросом, без всяких юнионов
А, то есть версия РНР так и осталась 5.4? Ну тогда флаг в руки, действительно придётся попотеть даже поднимая до 8.2.
Извините, но это просто чушь какая-то. Судя по всему, в части инъекций там остался весь ламерский код из предыдущей версии, и вы мечетесь, пытаясь применить дебильные советы из интернета, как уменьшить урон, и в частности не давать право на вставку. Хотя этого давно никто не делает за полной бессмысленностью.
Бороться надо с инъекциями, а не с их последствиями.
Очень смешной комментарий. Звучит как "очень плохо класть зажигалку в карман. Достаточно пришить ещё один". Вам не кажется, что "хранить еще и поле остатка" - это дополнительное действие, которое никак не подходит под формулировку "достаточно"? А достаточно как раз хранить только сами транзакции?
Другое дело, что с дополнительным полем можно будет реализовать атомарный апдейт и избежать двойных списаний без блокировки всей таблицы. Но тогда это должно быть поле в отдельной таблице с уникальным user_id. И делать транзакцию, где сначала идёт апдейт этой таблицы с условием, и роллбек если условие не выполнилось.
Непонятно, почему такую проверку нельзя было сделать и для INSERT. То есть вы, кажется, так и не поняли своё же решение, выставляя его так, что ключевым является избавление от инсерта, а не проверка перед записью.
Но главное, такая проверка не гарантирует перезаписи при одновременном сохранении формы. Но это пока не горит, а потом узнаете про борьбу с race condition поподробнее.
Статья вызывает смешанные чувства. С одной стороны, ещё года два назад такое сочинение пятиклассника "как я провёл этим летом" выпинали бы в чулан in no time. С другой - поляна настолько обезлюдела, что надо поддерживать и такие ростки.
Примерно то же самое относится и к оформлению. Вроде бы, статья про РНР, но в качестве иллюстраций... картинки интерфейса! Хотя куда логичнее было бы приводить примеры кода. Просто поставьте себя на моё место: я зашел в хаб РНР прочесть статью а почему-то рассматриваю картинки, которые вообще ничего не говорят о внутреннем устройстве системы.
Чисто для информации:
активная поддержка РНР 8.2 уже завершена. Если переписывать сейчас, то под 8.4. Хотя конечно там для вас разницы, пожалуй нету, но всё равно целевой версией надо ставить текущую.
Переписывать на PDO смысл сомннительный. Разница между PDO и mysqli минимальная. Единственное, принципиальное отличие - в mysqli нет именованных плейсхолдеров, вида :name, а только знаки вопроса. Если это для вас принципиально - то переписывайте конечно. Хотя я бы пока сосредоточился на более важных вещах. А потом уже при следующей итерации сразу перешел на какой-нибудь ОRM
Но если говорить в целом, то главное что вы довели этот проект до конца. Это самое важное. А опыт приложится.
Это совет из серии "Лучше быть здоровым и богатым, чем бедным, но больным". Давайте вы возьмёте на себя миссию объяснить заказчику, что затраты на проект надо помножить на два? А уже потом тот наймёт фронта, который расскажет автору как всё плохо.
Я очень хорошо читаю, что вы пишете. Ваши идеи сводятся к тому, что ПХП - язык для говносайтов, и надо было продолжать писать на нём говосайты, а не развивать язык, добавляя в него новую функциональность, и улучшая производительность. А энтерпрайз писать на других языках. Но религиозные суеверия и косность разработчиков зачем-то сделали из него язык энтерпрайз уровня.
Сам по себе ход вашей мысли понятен. Просто посылки, из которых вы исходите, довольно странные.
Не два, а полгода назад. Вы толком расскажите о проблемах, а не бурчите как обиженный пятиклассник.
Давайте вы будете подкреплять свои красивые слова фактами? У вас очень красивая и стройная проповедь, но с примерами в ней туго. При том, что все языки развиваются примерно одинаково, и берут друг у друга лучшее. И написать "догоняющий" можно про вообще любой. Тот же C# появился, чтобы "догнать" РНР на его поле.
Мне кажется, ваша проблема в том, что вы не можете толком сформулировать свою мысль. И в итоге подтягиваете трескучие аргументы даже не под конкретный тезис, а под неясную идею. И в итоге доходите до того, что начинаете ставить языку в вину тот факт, что он развивается и становится лучше.
Заголовок: Эксперты пояснили, почему в базе данных системы социального обеспечения США есть пользователи с возрастом более 200 лет
Текст: возраст человека может быть 150 лет и больше.
Картинка в тексте: если дата не указана, то берётся 1875, что в 2025 даёт 150 лет.
Новостная служба Хабра такая служба. Сколько читаю - столько не перестаю удивляться, как можно писать новости, но никогда не читать их.
Я думаю что вы это не специально, но у вас получился довольно иезуитский текст. Вы намешали верные посылки с неверными выводами и прямыми передёргиваниями. Делая, в итоге, то же самое, в чем обвиняете разработчиков языка: подгоняя аргументы под вывод.
Про религию и инерцию - всё верно. Но это ещё не вся правда. Помимо "любимого инструмента" есть ещё "любимая кодовая база" и "любимая инфраструктура". И решение сразу перестаёт быть таким простым, как "взять подходящий инструмент".
"PHP подходит для написания простых сайтов" - верно. Однако это совсем не значит, что не подходит для непростых. Даже чисто логически вы не можете сделать такой вывод. А практически - попытки "из кожи вон лезть" на самом деле дали очень неплохой результат. В РНР современная поддержка ООП, наравне с другими языками. Симфони вдохновлялась Спрингом, а Лара - Рельсами. В итоге РНР - это как бы два языка: процедурный "уэйл роу = муэскуэль фетч эррей" по гайдам из ютубочки, и вполне себе энтерпрайз с гексагональной архитектурой, DDD, TDD и чёртом в ступе.
Собственно, как раз в идее "всё переписать" куда больше уж извините, юношеского максимализма, чем практичности. Переписать пхпшный монолит на пхп-микросервисы с диспетчером на го? Отличная идея. "Переписать всё" и клепать круды на расте? А не попахивает ли это вашим же "подгонять инструмент под задачу"? При том что энтерпрайз - это как раз круды, на стероидах. И там важна в первую очередь осмысленная архитектура, а не язык. Тем более что всё равно писать будем на фреймворке, а не на голом языке. А разницу в коде на Симфе на Яве вы не враз заметите. Только по долларам и сможете отличить.
Вам-вам. Статья, конечно, халтурная, но ваш предыдущий комментарий тоже так себе. Я, кстати, и сам часто сталкиваюсь с этим - в голове самому себе всё ясно, а когда напишешь, то получается ерунда. Особенно когда читаешь по диагонали, а думаешь о своём.
В статье не предлагается использовать КРНР в своих проектах. Там предлагается использовать в своих проектах РНР, для логистики или крипты например. А Вконтактик привешен действительно не пришей собаке хвост, как не очень понятный пример "развития экосистемы". Хотя этому примеру уже сто лет в обед, и сейчас как пример стоило бы приводить скорее JIT.