Позвольте опять с Вами не согласиться . Это хорошо, что Вы уже так больше не делаете, значит есть рост . С чем Вас и поздравляю . Теперь по сути. Хоть как Вы отметили сейчас уже и не делали бы так, выводы которые вы описали в коменте выше, не совсем верны. 1)"Первый, сохранение файла действительно выглядит лишней операцией, но если посетитель ошибся при заполнении формы, можно отправить ему тотже файл, а не генерировать его заново." Нет Вы не правы, так нельзя делать. Потому, что в таком случаи намного упроститься задача распознавания капчи спам ботам. Если при не правильном вводе, картинка и код не обновляются, можно написать скрипт который будет пытаться распознать изображение с разными настройками до тех пор пока ему это не удастся, ну или банальный полный перебор (хотя это я уже утрирую ). 2)Второй, PHP сессии по-умолчанию хранятся в файлах, но в принципе можно использовать любой вид хранилища, в т. ч. и БД. Да по умолчанию в файлах. Но на нормальных серверах стоит МекКеш который позволяет хранить в оперативе. Я согласен ПХП сессии тоже не панацея и с ними надо быть поосторожней так как на ресурсах с большой нагрузкой тоже будут проблемы если уж очень активно и там где не нужно их использовать. Но все же это намного оптимальней чем БД. А если использовать сесии Code Igniter которые хранятся на стороне клиента в зашифрованых кукисах проблема вообще решается очень красиво. 3)Третий, удаление устаревших картинок и записей в БД не обязательно будет происходить по одной, т. к. удаляются все записи старше какого-то момента. К тому же эту операцию можно вынести в отдельный скрипт и запускать cron'ом. Если трех колесный волосипед переделать в двухколесный, суть особо не меняеться . Зачем придумывать жопу, а потом еще делать какие то тело-движения которые грузят сервер, что бы эту жопу почистить . Тем более пихать это все еще и в кронтаб, что вообще понижает кросплатформеность приложения. Далеко не на всех хостингах Вам удастся запихать задачу в крон. Ну по поводу альтернатив капчи . Чем больше Вы будете усложнять логические примеры, тем больше людей не смогут зарегиться.
.jpg)
Так как надо учитывать тот момент, что есть "люди-бараны" . Которые с капчей с трудом справляються. По поводу нагрузки на сервер не согласен. Совсем даже не уменьшит. За счет чего Вы видите минимизацию нагрузки в таком случаи? P. S. Отчасти Вы правы. Учимся все на ошибках. Чужих и своих. Но тут вопрос насколько быстро учимся.
Чем больше будет качественных материалов, тем быстрей будем учиться. Если новичку в каждой статье вбивать в голову, что оптимизация очень важный аспект при разработке, тем быстрей он это усвоит и будет пытаться применять это на практике. Пускай в своем пока виденьи далеком от идеала, но все же это уже, что то. Это уже похоже на какой то стиль. Не хочу Вас обидеть.
.jpg)
Метериал написан Вами не плох. Но мог бы быть и лучше . Просто потом приходят на собеседование программеры, которые делают запросы в цыкле и вместо свято уверены, что инфу лучше хранить в текстовых файлах а не в БД .