О непорядочных людях. Обман разработчика скрипта.

Не переживайте так :) Вступая в дискуссию, читаю я архивнимательно ;)

Ваши слова:

(/ru/forum/comment/1103652)

Сначала о тяжести запроста, а далее - "глубже копать лень" :)

Или может ткнёте меня носом, где Вы делали выводы исходя из чего либо ещё, отличного от запроса. Был бы премного благодарен :)

ПС.

Да зачем во всей? Половины достаточно :)

Основная часть после FROM = 3 левых джойна.

Аватарки видим? :) Видим = +2

Репу видим? :) Видим = +1

Итого как минимум шесть.

ППС. И я Вас прошу, если где-то и в каких-то случаях Джойн оказывается не лучшим выбором, то не надо сразу же бегать и кричать на все стороны, что "Джойны - это зло".

Если бы они были таким злом, безумно грузящим сервер, то врядли бы существовали столько разных (лефт, райт, иннер) конструкций, и использовались производителями серверов БД :)

Смех да и только.

Чтобы не быть голословным:

Этот запрос с JOIN занимает от 0,001663 до 0,002422 секунды.

Он же, но разбитый на четыре занимает на обработку от 0,002186 до 0,004386 секунды.

Почувствуйте разницу в ~ 25%.

Советую использовать join хотя бы потому, что у некоторых хостеров стоят лимиты обращений к базе и при достаточной нагрузке ваше творение попросту будет заблокировано сервером.

У нашего скрипта закодирована только админка! Все остальные файлы открыты, можете оптимизировать сколько угодно. ;)

Да !!! ... обсуждение плавает туда - сюда. Речь об одном, потом о другом. Начали с обсуждения о том, как ведут дела разработчики, и как поступают с клиентами - в итоге закончили SQL запросами. Все это конечно интересно, но не по данному топику. Может и правда тема уже себя исчерпала и пара её просто закрыть ?

А то топикстартера забанили, за излишнюю хамливость, разработчкики открестились, что "сам дурак", за что получили большой респект от массы народу (судя по репе). И, как говорится все в шоколаде. А проблема, как была, так и осталась. И проблема не каталога конкретного, а отношения разработчиков к клиентам. ИМХО все вернулось на круги своя.

Зингельшухер, а зачем тогда вообще JOIN придумали да ещё и в вариантах INNER и RIGHT? Или по Вашему лучше связывать так?

FROM T1, T2 WERE T2.subid=T1.id

PS я прошел по своим запросам и насчитал до 15 INNER JOIN в обном из запросов, значит я не умею их писать, а жаль, буду учиться.

dkameleon, извиняюсь за плагиат, не дочитал до конца трейд прежде чем ответить :)

Да забейте вы, ёлы-палы. (я устал уже отмазываться) мало ли что по пъяни ляпнул, чё теперь всю жизнь меня попрекать будете ?

а причем тут разработчики? phtml на нормальных хостингах обработывается так как и php то есть его невозможно просмотреть в plain text формате

Не знаю, как кто, а я еще при первых опытах работы с PHP усвоил, что пароли и другая закрытая информация должны храниться в файлах, а еще лучше - в директориях, доступ к которым из браузера невозможен ни при каких обстоятельствах.

И если какой-то производитель продукта об этом не знает или не считает нужным предупредить пользователя о возможных проблемах, то именно производитель, а не пользователь должен нести ответственность за последствия использования злоумышленниками этой дыры.

Когда ощущение от первых опытов пройдёт, откроется страшная истина. :))

Реализация указаного Вами принципа будет означать проблему с распространением продукта.

Пользователь хочет что бы всё что относится к софтинке, размещалосьв директории софтинки.

Если ему рассказать что нужно залить совсем не туда... а подыскать куда... то пользователь просто скачает тот скрипт которые не будет парить ему мозги. Суровая правда жизни :)

такое впечатление что никто никгода не слышал про шифрование паролей - а на дворе 2006 год - 21 век уже, друзья!!!!

технологии шагнули вперед, а в многоуважаемом PHP появилась функция sha1().

Ну это так, на заметку. Практически офф.

ПЫС хотя, честно говоря, весь топик не читал. может и открылась кому такая тайна.

Народ, может об этом уже говорилось, но далее 8 страницы меня уже не хватило :).

В этом баге виноват РАЗРАБОТЧИК. Его можно было легко устранить еще на стадии первичного тестирования самой первой версии софта. Или банальным использованием .php, или просто через .htaccess обязать интерпритатор обрабатывать расширение .phtml в папке include.

Если разработчик не предусмотрел этот баг (сколько хостингов использовал, не помню, чтобы хоть один поддерживал .phtml) - грош цена этого софта.

PS Я тут щас почитал описание версии Профессионал. Народ, вы действительно готовы отдать за этот функционал 150 баков (щас уже 200 просят)? А я-то на CMS заморачиваюсь, вот она, золотая жила :).