boronick, послушайте, зачем вам вообще база данных? Если всё так накладно.
Храните в текстовом файле, через палочку. Тогда вообще ни одного запроса не понадобится. Вот где профит-то!!!
Самый ужас здесь, конечно, это "а можно в отдельной таблице, но это накладнее".
Удивительно экономный народ - эти программисты.
Нижнее бельё они носят, хотя это очевидно "накладнее", чем без трусов ходить.
А вот о бедной базочке данных прям заботятся, как бы ей "накладнее" не вышло.
alexalexes, насчет "читабельности" я не уверен. Следует помнить, что бессмысленная фича "num_rows" существует только в mysql, другие базы данных как-то обходятся без неё.
запросить count(*) будет, конечно, более осмысленным действием, но опять же, чисто технически это ничем не лучше фетча запрошенной строки.
а обработку ошибок надо отдать исключениям
по умолчанию mysqli не кидает исключения при ошибках
нарушение уникальности - не единственная ошибка, которая возникает при выполнении запроса
данный код будет выдавать "Вы уже оставили заявку" при любых ошибках с БД, затрудняя отладку
в целом этот ответ - типичная попытка решить несуществующую проблему.
fetch вернёт null если запрос не вернул строк, и условие if ($stmt->fetch()) не будет выполнено
AgentSmith72, если вас интересует производительность на уровне регистров процессора и отдельных байт памяти, то РНР - не ваш выбор.
Типичное приложение РНР работает с хранилищами данных к которым обычно ходит по сети. Память сразу выделяет большими кусками. Живет от 1 сотой до единиц секунд. таких обращений к функциям - и в самом РНР, и в хранилищах, к которым он обращается, и в веб сервере - тысячи.
Разница с вашими страданиями по обращению к памяти в несколько порядков. Если заменять разницу в обработке запроса целиком, то увидеть её будет невозможно. В лучшем случае - на специально придуманном тестовом стенде, который измеряет вызовы сферически функций в вакууме
не ссылки, а имена файлов наверное?
ну так их выковырять - дел на 30 секунд.
при том что привести в "человеческий вид" - от 30 минут до двух часов, в зависимости от квалификации исполнителя.
выбор за вами, эстетичность против практичности
Понимаю. Оптимизация производительности головного мозга в тяжёлой форме.
Языка мы толком не выучили, гуглить вообще никогда не умели, но уже стрррашно озабочены эффективностью использования системных ресурсов.
Оооо, да тут всё серьёзно.
то есть мы тут на тропе войны, и ищем аргумент для спора с опытным разработчиком
чтобы кинуть ему все 300 байт разницы в его самодовольную ухмылку
Храните в текстовом файле, через палочку. Тогда вообще ни одного запроса не понадобится. Вот где профит-то!!!