эм, с чего бы это? у него
1) последовательность запроса именно astatus, abrub;
2) подзапрос имеет WHERE astatus > 0;
как при этом получается индекс (adrub, astatus) ?
почитаю ка про оптимизатор мускулевый)
в принципе, могу предположить, что последовательность условий в where может поменять оптимизатор самой базы данных(надо бы проверить завтра), но тогда получится, что нужен отдельный индекс для astatus.
найди доки по синтаксису mysql
полно в инете на русском языке
например есть запрос replace который
либо update либо insert в зависимости от ситуации
и т.д.
Сам по себе replace заменяет определенный текст, на другой.
как INSERT - ну насколько я понял он должен добавлять строки.
А вот как сделать Update всего столбца, я помощью запроса выше - понять не могу ...
Хотел зделать что-то типа статуса, будут выводится ники игроков из таблицы "Score", если игрок есть в таблице "Admin" - напротив его ника писалось "Adm", если в "Mod" - "Mod", если игрока нет ни там ни там - "plr" Смущение
немного не понятно, почему бы не завести в одной таблице с юзерами поле, где указывать их тип? зачем на каждый тип пользователей создавать отдельную таблицу? просто подумал, как бы сделать запрос, который будет автоматически это всё проставлять, и не представил)
всё, что могу предложить - это что то вроде
писали бы вы на С++ такие ноимера бы не прошли
выкинули исключение с класса а класс остался в памяти
(знаменитая memory leak)
через пару дней бы сервер остался без памяти а еще пару дней бы ушло найти где проблемма
это значит, что исключения развивают безолаберность, а нетипизированность возврата функций - наоборот, ведёт к духовному и профессиональному росту?)
если у вас одна ошибка(неверная комбинация логина и пароля), то и catch будет один.
во первых не один - у вас могут быть иклблючения по работе с БД
если говорить про конкретно этот случай, то catch будет один, потому что обычно абсолютно всё равно, какая причина помешала пользователю залогиниться, результат один - в логине отказано. а если нужно обрабатывать разные ситуации, то catch будет больше, но и IF в вами предложенном решении будет больше ( в самом деле, не будете же вы писать пользователю, что у вас база данных померла.)
по поводу читаемости - тоже прихожу к мысли, что try{}catch{} становится читабельнее, потому что ожидаешь, где искать обработку ошибок, а не выискиваешь её в каждом встречном if.
и catch(SQLException e) выглядит, кстати, красивее, чем if(!is_class($variable) and $variable =="не удалось выполнить запрос");
а потом парсить строку на содержание что бы понять, что с ней делать
Зачем парсить? Вы знаете что это ошибка при чем ошибка наперед известная (неверныая комбинация логина или пароля) вот и выводите
а пятиэтаэный
catch(...)
catch(...)
catch(...)
catch(...)
catch(...)
в каждой функции чем лучше
если у вас одна ошибка(неверная комбинация логина и пароля), то и catch будет один.
А получение экземпляра класса User и его проверка в коде на принадлежность к этому классу вызывают недоумение.
Меня вообще с момента начала изучения слегка напрягает возможность возвращать смешанное значение в PHP, это подразумевает, что после вызова функции я должен ещё и проверять, что же она мне вернула... неприятно.
Проверять валидность в конструкторе - абсурд. Ты создаешь екземпляр класса
разумеется уж валидного. Если ты проверяешь в конструкторе ты УЖЕ создал экземпляр. А если он не валидный и что - прибивать его?
Вообще в конструкторе не принято выполнять действия которые могут вызывть ошибку или исключение (ходить в базу например) - задача конструктора - проинициализировать члены класса.
Плодить иерархию валидаторов - это значит писать "индусский" код и противоречить принципу инкапсуляции.
Самое грамотное - создать в классе СТАТИЧЕСКИЙ метод который будет валидировать данные и возвращать екземпляр класса или там null или false или исключение выбрасывать. Тем более что статический метод будет иметь доступ к приватным членам класса. Да и не нужны в большинстве случаев специфические валидаторы.
В случае с юзером - статический метод login(name,pass)
либо возвращает екземпляр юзера после проверки в БД, либо например строку с описанием ошибки.
я просто почему спрашивал... видел достаточно кода(на яве или шарпах), где проверка валидности данных проходила исключительно внутри класса объекта, и при некорректности просто бросалось исключение, в том числе при первичном заполнении пустого объекта. А во внешнем коде ни о каких проверках уже не было и речи.
С другой стороны, я читал где то о проектировании приложения так, что все данные проверяются сразу на входах, а внутри приложения проходят ТОЛЬКО валидные данные, которые больше нигде не проверяются.
Вот и хотел узнать, как в PHP удобнее или правильнее поступать)
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 92
