> Почему бы не показать в 95% более релевантную для него страницу?
Потому, что он мог перейти из поисковика или из закладок, или по ссылке из аськи на конкретную страницу, а не туда, куда вы его хотите перекинуть. Если вы считаете, что у пользователя «нет никаких желаний», так показывайте ему сразу при заходе страницу оплаты VIP-акаунта, что уж там. Также, кстати, страница с подобным редиректом вполне может вылететь из поискового индекса.
Тем, что пользователя редиректят не спрашивая его желания и не выясняя его намерений. Хороший тон — показать заметную строчку сверху «Не желаете ли перейти на сайт вашего родного города, господин?», а вот молча редиректить, не спрашивая и не объясняя — это невежливо.
Так массив из 100000 значений надо как-то вписать в запрос, преобразовав в строку (он же у вас каждый раз новый), потом его надо передать, потом его должен разобрать из строки сервер SQL, один хрен вам приходится кучу чисел по сети гонять, вместо того, чтобы сразу в приложении на месте перемножить.
Тут еще такой момент: с ростом нагрузки поставить второй веб-сервер для приложения гораздо проще дешевле, чем разнести базу данных на 2 и более серверов (это потребует переписать код) — потому традиционно стараются грузить приложение, а не базу данных (в хорошем масштабируемом приложении БД делает только самые простые запросы по индексам, без JOIN и прочих сложностей).
> Может статься, что страниц с одинаковым содержимым (справка, статьи) будет порядочно
Если они одинаковы для всех городов, выносите их на главный домен либо например на help.objava.ru и все. Нечего дублировать контент. Не вижу никакой проблемы. Если почти одинаковы (различаются адресом и номером телефона) — можно добавить в УРЛ параметр ?forCity=1234
Нет, нету, единственный способ, это через многократные if(), и это только усложняет разбор запроса сервером. Что ж у вас за язык программирования такой, что быстрее заставлять MySQL умножать числа :)
Во-первых, вы очень плохо задали вопрос, что трудно его понять.
Во-вторых, вы усложняете себе жизнь по моему. Конечно, можно засунуть массив в SQL запрос, отправить его на сервер, там перемножить и вернуть результат, но зачем? Это же наркоманство какое-то. Умножать надо на стороне приложения.
Если вам принципиально умножать на сервере — создайте таблицу с значениями из массива, делайте JOIN и перемножайте хоть до посинения:
SELECT SUM(table.field * arrayTable.value) FROM table LEFT JOIN arrayTable ON table.key = arrayTableKey WHERE table.key IN (....)
Есть понятие покушение на совершение преступления, или как-то так. То есть если ты в знак протеста против политики Путина запланировал взорвать Кремль, сделал бомбу, заложил ее, но в последний момент передумал взрывать, или например, тебе помешали это сделать, все равно могут посадить, хоть и ущерба вроде не было.
Вы противоречите сами себе. Если это набор классов для встраивания в *любые* приложения, вроде библиотеки, вы не должны вообще встраивать обработчики ошибок и использовать set_error_handler, а должны использовать стандартные средства PHP, например trigger_error() с разными уровнями или исключения (throw new MyLibraryException) для сообщения о непредвиденных и неисправимых ошибках (вместо даты передана строка, вместо массива передано число) и коды возврата для обрабатываемых ошибок (типа пользователь с данным id не найден). То есть так же, как ведут себя стандартные функции PHP. Что касается перехвата ошибок внутри самой библиотеки, по моему, это проще делать кодами возврата (чтобы не писать всюду try/catch).
Игнорируемые исключения — все же неправильно, зачем их выбрасывать, если они потом игнорируются? И в какой ситуации это вообще возможно? Что-то я даже представить себе не могу.
А почему на продакшене замечания надо игнорировать? Они там какие-то другие? Или боитесь, что заказчик увидит косяки?
И поверьте, простые подходы лучше сложных. А то, посмотрите на тех же явщиков — у них аж несколько огромных библиотек (с XML-конфигами) только для логгирования написано, в то время, как у нас в PHP для этого достаточно 1 строчки file_put_contents().
Если человек физически крепкий, занимается спортом, и может, например в драке успокоить другого физически крепкого человека, то армия действительно может оказаться полезным опытом, лучше разбираться в людях станет, будет много времени подумать над смыслом жизни, ценностями и прочей философией.
А если здоровье не очень, то лучше не идти, так как можно потерять его окончательно.
> а я и не использую «body onload». его использует google чтобы проверить скорость загрузки моей страницы
1) Стать честным человеком и купить номальный хостинг
2) Обхитрить кодеров гугла: в конец страницы вписать (script) setTimeout(function() { document.body.onload && document.body.onload(); }, 500);
Насколько я знаю, SMB — кривой и проприетарный протокол, но лучшего способа организовать удаленный (и удобный и кроссплатформенный и позволяющий открывать и частями читать/писать файлы) доступ к файлам сегодня нету.
Я юзаю виртуалбокс, хост 32 бита и Windows XP, клиенты — линуксы и винды. Проблем нет, ничего не падает. Единственное, что макось не идет под ним, печально ((
Потому, что он мог перейти из поисковика или из закладок, или по ссылке из аськи на конкретную страницу, а не туда, куда вы его хотите перекинуть. Если вы считаете, что у пользователя «нет никаких желаний», так показывайте ему сразу при заходе страницу оплаты VIP-акаунта, что уж там. Также, кстати, страница с подобным редиректом вполне может вылететь из поискового индекса.