Паттерны программирования и PHP

Цитата ("tvv"):

Еще раз, если возможна ситуация, когда в базе данных могут находиться данные, на которые ничто не ссылается и которые не используются, или наоборот могут быть ссылки на несуществующие данные, то это — прямое нарушение целостности. В Вашей схеме это возможно.

Конкретно - что в данном случае будет данными, которые не используются, либо ссылки на несуществующие данные? Вы все время отвечаете на общем абстрактном уровне, давайте конкретику.

Цитата ("tvv"):

Этому слову столько же лет, столько и слову нормализация.
Более того, принципы денормализации были сформированы в то же самое время, что и принципы нормализации, и теми же самыми теоретиками, и с тех пор практически не изменялись. И я использую это в проектах моих клиентов там, где это действительно уместно, причем последние лет 15. Также, я говорил о денормализации в моем сообщении к Вам от 16:54 (посмотрите пункт 4).
Итак, где же тут якобы новое "изменение взгляда на организацию БД" (c) ?

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

Цитата ("tvv"):

Вы предложили аналогичное решение, что и работать под рутом.
А именно, получать доступ к БД пользователем с высоким уровнем привилегий (ибо иначе не получится проводить DDL операции), вместо того, чтобы дать лишь возможность производить DML операции.
Вам действительно нужен конкретный пример, чтобы показать, чем это плохо давать пользователю БД высокие привилегии, Вы действительно этого не понимаете?

Не передергивайте. Дать возможность определенной группе пользователей (администраторам) возможность ALTER TABLE - это совсем не то же самое, что работать под рутом.
И я именно прошу показать пример, каким образом именно вот эта конкретно возможность (а не абстрактные высокие привелегии всем подряд), будет является риском? Я именно этого не понимаю, и именно все время прошу показать, и даже допускаю вероятность, что я чего-то упустил в области безопасности сайтов, - но вот извините, но абстрактное "так низя!" меня почему-то не убеждают.

Цитата ("tvv"):

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

Так Вас же никто не заставляет продолжать разговор. А оскорбления Вы первый начали раздавать, так что к себе упреки и верните.
А вот начинающие ребята, возможно, как раз и задумаются, прочитав тему, и не станут вот так бездумно делать все, что великие гуру от программирования говорят. Уже благо.

Цитата ("tvv"):

В этом случае ручное вмешательство действительно не обязательно, если админ обязательно (!) будет заходить в форму редактирования регионов/методов после сбоя.

Знаете, если после сбоя админ пойдет спать... весьма странным будет такое поведение. Ибо адекватная реакция админа на сбой будет именно зайти и убедиться, что все в порядке.

Цитата ("tvv"):

А можете ли написать сценарий, что будет при удалении метода доставки?

А здесь обратная последовательность. Сначала колонка удаляется.

Цитата ("tvv"):

И еще. Значение NULL все же занимает место. И NULLABLE поля обрабатываются движком базы данных медленнее, чем NOT NULL поля, ибо в этом случае используется другая логика (ряд дополнительных правил, похожих на правила троичной логики).

Согласен, с NULL еще надо бы оптимизировать, например, использовать -1.

Цитата ("raznomir"):

Знаете, если после сбоя админ пойдет спать... весьма странным будет такое поведение.

Странно - это когда админ бегает и костыли проверяет.

Цитата ("raznomir"):

А здесь обратная последовательность. Сначала колонка удаляется.

И сразу же восстанавливается первым костылем. Бугага.

Честно говоря странно видеть такие споры :o Мое мнение:
- Чем меньше прав у пользователя тем лучше. Это касается наверное вообще всего. Не только изменения структуры БД. Движение от "все запрещено" с разрешением необходимого даст наиболее безопасный вариант.
- Нормализация это хорошо и правильно. Да, она происходит часто в ущерб производительности, но производительность поднимается в другом месте
- Денормализация сродни кешированию. Как и кеширование позволяет поднять производительность, снизить нагрузку на БД, НО при этом остальное должно быть нормализовано. Тогда получается связка из БД без избыточности и целостная, а производительность за счет кеширования.
Из этого следует
- Права на изменения таблицы избыточны так как есть вариант, когда они не нужны.
- Нужен изначально нормализованный костяк, основной источник данных, который будет использован как эталон для загрузки в кеши. Само кеширование вопрос второй и он слабо зависит от исходных данных.
Вот такое вот ИМХО.

Ну да, в целом сказали все правильно, кто ж с этим спорит?
Спор в другом. Я утверждаю, что вариант решения с добавлением колонок вполне допустим в ряде случаев, а tvv утверждает, что нигде и никогда не допустим, прям аж по рукам всех бить надо. Но при этом мне никто так внятно и не сказал, почему собственно недопустим, только общие фразы в стиле "так не положено".

Цитата:

Я утверждаю, что вариант решения с добавлением колонок вполне допустим в ряде случаев, а tvv утверждает, что нигде и никогда не допустим, прям аж по рукам всех бить надо.

НУ несколько иначе надо ставить вопрос, на мой взгляд. права по изменению таблиц это избыточные права. Изменение структуры БД в процессе работы, как изменение самих данных это тоже не очень хорошо, так как может вызвать трудности при восстановлении (tvv об этом писал). И всего этого можно избежать, если не применять такое решение. Т.е. вот они недостатки. Теперь надо положить на другую чашу достоинства, оценить их и тогда будет видно в каких ситуациях такое решение оправдано. В чем достоинства?

Цитата ("raznomir"):

* меланхолично: а теперь расширьте этот принцип максимально далеко - получим, что посетителя надо вообще на сайт не пускать и.т.д, и.т.п. А потом и комиссия по морали контент начнет фильтровать - крейзи-смайлека не нашел...

Поправлюсь. Должен быть минимальный набор НЕОБОДИМЫХ прав. Обычному пользователю ПК права администратора в повседневной жизни не нужны. Они избыточны и опасны. В итоге пользователи, получая вирус запуская его с этими правами получают больший урон, чем пользователи с урезанными правами. Всего этого нельзя учесть, но если двигаться от запрета всего, выдавая только необходимое, то набор прав будет гарантированно минимально необходимым - безопасность в этом месте будет максимально возможной.

friq, это опять общие фразы. Я же не утверждаю, что мое решение идеально, а все прочие решения идут лесом. Я утверждаю, что оно допустимо, и имеет свои преимущества. Если же Вы тоже утверждаете, что оно недопустимо, то давайте аргументированный конкретный ответ, в чем именно недопустимо. Пример с вирусом некорректен - ибо если у пользователя есть права на INSERT, UPDATE и DELETE (а для редактирования регионов/методов в любом варианте без этих прав не обойтись), то дополнительные права на ALTER TABLE ну никак не повысят риски - а не все ли равно будет, если вирус обнулит все значения в базе или удалит все строки, либо он поменяет структуру? Степень урона на одном уровне.

Цитата ("frig"):

Обычному пользователю ПК права администратора в повседневной жизни не нужны.

Я где-то утверждал, что надо давать обычному пользователю ПК права администратора?

Цитата ("raznomir"):

Я утверждаю, что оно допустимо, и имеет свои преимущества.

Я не говорю, что недопустимо. Я предлагаю
Цитата ("frig"):

Теперь надо положить на другую чашу достоинства, оценить их и тогда будет видно в каких ситуациях такое решение оправдано. В чем достоинства?

Оценить достоинства и интересуюсь у вас в чем они состоят.

Цитата ("raznomir"):

Пример с вирусом некорректен - ибо если у пользователя есть права на INSERT, UPDATE и DELETE (а для редактирования регионов/методов в любом варианте без этих прав не обойтись), то дополнительные права на ALTER TABLE ну никак не повысят риски - а не все ли равно будет, если вирус обнулит все значения в базе или удалит все строки, либо он поменяет структуру? Степень урона на одном уровне.

Нельзя оценить все аспекты. Можно применить наиболее безопасную схему и анализировать уже ее. Да, возможно урон от alter table будет не больше, но есть много других неприятных моментов. Просто удаление или изменение данных - слишком очевидно, а вот если изменить структуру, подменить типы, то замечено это будет не сразу, а вот на нагрузку может повлиять существенно. В первом случае проблема будет быстро обнаружена и устранена, во втором случае долго и счастливо отравлять жизнь.
Речь не о конкретном ALTER TABLE а о избыточности прав. Если можно избежать - то нужно избежать лишних прав. Если нельзя избежать, то надо оценивать, что будет получено за эти вот права. Опять приходим к необходимости описать достоинства и положительные стороны метода.

Цитата ("raznomir"):

Я где-то утверждал, что надо давать обычному пользователю ПК права администратора?

Я где то утверждал, что вы утверждаете? Это был распространенный пример избыточных прав.

Ух ты, вы все спорите?
Цитата ("raznomir"):

* меланхолично: а теперь расширьте этот принцип максимально далеко - получим, что посетителя надо вообще на сайт не пускать и.т.д, и.т.п. А потом и комиссия по морали контент начнет фильтровать - крейзи-смайлека не нашел...

Я видел такое изречение

Цитата ("Lisio"):

Одно из них - в вебе сервера в разы мощнее большинства пользовательских компов. Потому многие считают обязательным набыдлокодить.
Большинство даже не знает, что echo "date" тратит больше времени, чем echo 'date'. Другие отмазываются тем, что там тысячные доли секунд только выигрываются. Но забывают, что 10000 пользователей + поисковики, да все помноженное на сотни таких echo дают уже гораздо больше нагрузки. И так во всех случаях. Стараются везде и во всем использовать наименее оптимизированные функции.

Спасибо, посмеялся. Вы тоже экономите на спичках и пишете везде ' ' ?

Был у меня один товарищ с подобными убеждениями. Когда я ему показал результаты бенчмарка на 10000 запросах (не говоря уже о реальном тестировании) - его запал приостыл, т.к. разница вышла не больше одной сотой.

razmomir, склонен думать также, как и tvv. Чтение ваших комментариев - доставляет. Вам говорят как должно быть, а вы - "нет, это все бред, вот я знаю как надо". Люди годами это применяют, а вы изобретаете какие-то свои велосипеды, совсем невалидные и костыльные.

P.S. Во русскоязычном фрилансе все до сих пор плохо с веб-программированием...жаль

Цитата ("ArtLab"):

Спасибо, посмеялся. Вы тоже экономите на спичках и пишете везде ' ' ?

А вы всегда жмете shift, чтобы поставить двойные кавычки там, где это не надо? Действительно, смешно. Можно еще и www. набирать при вводе адреса в браузере, это же такое удовольствие, целых 4 раза кнопки пожмякать. А я как-то привык сразу писать максимально оптимизированный код, включая экономию на спичках, зажигалках и огнеметах.

Есть один товарищ, создатель Slaed CMS, он любит писать так: echo "".$var.""; Ну так, на всякий случай, вдруг $var не строкового типа. Спичек ему также не жалко, коробками разбрасывает.

Не вижу абсолютно ничего плохого в использовании любых способов повысить производительность, даже на десятую процента. Абсолютно не вижу в этом плохого. От меня не убудет, если я напишу так, как правильно, а не "лишь бы сдать проект". Как говорится, из копейки рубль складывается.

Цитата ("Lisio"):

А вы всегда жмете shift, чтобы поставить двойные кавычки там, где это не надо? Действительно, смешно. Можно еще и www. набирать при вводе адреса в браузере, это же такое удовольствие, целых 4 раза кнопки пожмякать. А я как-то привык сразу писать максимально оптимизированный код, включая экономию на спичках, зажигалках и огнеметах.

Не поверите, я еще и вслепую набираю, поэтому мне всеравно, что с шифтом набирать, что без него, тоже самое - как с ввв или без него

Если вы экономите на спичках - у вас параноя. Узкие места чаще всего на на этих местах бывают в приложениях, поэтому нет смысла на этом экономить, если у вас база криворуко сделана или не оптимизирована под нагрузки.

Цитата ("Lisio"):

Есть один товарищ, создатель Slaed CMS, он любит писать так: echo "".$var.""; Ну так, на всякий случай, вдруг $var не строкового типа. Спичек ему также не жалко, коробками разбрасывает.

Это уже лично его проблемы, как он любит писать, ведь правда? Только пусть сам свой такой код и поддерживает.

Цитата ("Lisio"):

Не вижу абсолютно ничего плохого в использовании любых способов повысить производительность, даже на десятую процента. Абсолютно не вижу в этом плохого. От меня не убудет, если я напишу так, как правильно, а не "лишь бы сдать проект". Как говорится, из копейки рубль складывается.

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

Немного прочитав тему увидел и другие ваши "оптимизации" - писать свои "паттерны"

Цитата ("ArtLab"):

Не поверите, я еще и вслепую набираю, поэтому мне всеравно, что с шифтом набирать, что без него, тоже самое - как с ввв или без нег

Тот же метод набора, но мартышкин труд не делаю.

Цитата ("ArtLab"):

Если вы экономите на спичках - у вас параноя. Узкие места чаще всего на на этих местах бывают в приложениях, поэтому нет смысла на этом экономить, если у вас база криворуко сделана или не оптимизирована под нагрузки.

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

Цитата ("ArtLab"):

т.к. вы тратите свое время на ненужные телодвижения.

Я не нажимаю Shift к примеру. Это делаете вы. Оптимизированный код как правило намного короче неоптимизированного. Иначе и быть не может.

Цитата ("ArtLab"):

Данный пример как раз говорит, что вы - любитель оптимизировать все подряд.

Именно, всего подряд. И не скрываю этого. Еще делаю так, чтобы база работала как электроны в БАК, весь html был валиден на 100%, а php не выдавал ни одного warning'a. Я разве это скрываю? Я параноик в плане оптимизации и секьюритизации кода, и никогда этого не скрывал и не стеснялся.

Цитата ("ArtLab"):

Немного прочитав тему увидел и другие ваши "оптимизации" - писать свои "паттерны"

Верно. Так и есть, предпочитаю анализировать чужой код, но писать своё, под свои нужды и задачи со своим стилем программирования и понимания оптимизации на всех уровнях. Поверьте, мне не важно, что вы смеетесь, ради Бога, в вопросах оптимизации мне глубоко плевать на мнение остальных по вопросу: стоит ей заниматься или нет и в какой степени.

Цитата ("Lisio"):

Верно. Так и есть, предпочитаю анализировать чужой код, но писать своё, под свои нужды и задачи со своим стилем программирования и понимания оптимизации на всех уровнях. Поверьте, мне не важно, что вы смеетесь, ради Бога, в вопросах оптимизации мне глубоко плевать на мнение остальных по вопросу: стоит ей заниматься или нет и в какой степени.

Вы видимо в команде не работали, по жизни скорее как фрилансер-одиночка бываете, поэтому игнорируете стиль программирования и всеобщие стандарты.

Как только с этим столкнетесь - будет очень больно переучиваться. А если не столкнетесь - то скорее всего больших проектов вам таки не видеть, т.к. их дают как раз командам. А там семеро одного не ждут (думаю намек понятен).

Цитата ("Lisio"):

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

Да, я игнорирую и буду игнорировать, т.к. это экономия на спичках. Я лучше посвящу свое время более существенным вещам, как оптимизация базы или серверные оптимизации - кешер байт-кода, установка nginx вместо апача, вынесением статики на отдельный хост, поставлю мемкеш и буду кешировать туда и т.д. Все это даст намного больший прирост производительности, чем экономию на спичках, вроде замены " на ' везде, лишь бы быстрее работало на сотые доли секунды.

Я работал и работаю с средне-нагруженными проектами, да, может это не миллионы посетителей в день, но до тысяч 5-10 - точно и готов с отвественностью сказать, что то, что было создано - мало того, что не жрет ресурсы - еще и имеет запас прочности в раза 2-3. Поэтому думаю вы зря про "база у вас не то что под нагрузки не оптимизирована, а даже на простых порталах жрет ресурсы как на выделенном сервере". Пожалуйста, не говорите того, в чем вы не уверены, иначе это просто очернение.

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

Буду рад выслушать ваш опыт.

Ой-ёёё. Возбудил народ

Цитата ("Lisio"):

А вы всегда жмете shift, чтобы поставить двойные кавычки там, где это не надо? Действительно, смешно. Можно еще и www. набирать при вводе адреса в браузере, это же такое удовольствие, целых 4 раза кнопки пожмякать. А я как-то привык сразу писать максимально оптимизированный код, включая экономию на спичках, зажигалках и огнеметах.

120% согласен. Сам так думаю и делаю.
Цитата ("Lisio"):

Есть один товарищ, создатель Slaed CMS, он любит писать так: echo "".$var.""; Ну так, на всякий случай, вдруг $var не строкового типа. Спичек ему также не жалко, коробками разбрасывает.

И сам тоже видел такой бредятенский код в Slaed CMS...у нескольких людей спрашивал мол зачем...может я чего-то не понимаю...зачем так..
Почему не

(string)$var

или пусть

"".$var

Цитата ("trueW3C"):

Цитата (Lisio):
Есть один товарищ, создатель Slaed CMS, он любит писать так: echo "".$var.""; Ну так, на всякий случай, вдруг $var не строкового типа. Спичек ему также не жалко, коробками разбрасывает.

И сам тоже видел такой бредятенский код в Slaed CMS...у нескольких людей спрашивал мол зачем...может я чего-то не понимаю...зачем так..
Почему не
Код:
(string)$var

или пусть
Код:
"".$var

Если используете echo, то нет смысла явно делать подобное преобразование типа. Так как это делается автоматически: ссылка

Цитата:

Converting to string

A value can be converted to a string using the (string) cast or the strval() function. String conversion is automatically done in the scope of an expression where a string is needed. This happens when using the echo() or print() functions, or when a variable is compared to a string .

То есть, в этом случае было бы правильно использовать лишь:

echo $var;

Там не только echo был...там повсюду такой бред

Цитата ("ArtLab"):

Вы видимо в команде не работали, по жизни скорее как фрилансер-одиночка бываете, поэтому игнорируете стиль программирования и всеобщие стандарты.

Теперь моя очередь смеяться як конь Вы всей командой изучаете стандарты индийского программирования? Когда всеобъемлющая оптимизация нарушала стиль и стандарты? Китай и Индия - это не всеобщие стандарты.

Цитата ("ArtLab"):

А там семеро одного не ждут (думаю намек понятен).

Вполне понятен. Вы все еще считаете, что написание изначально быстрого кода требует больше времени. В этом ваша возможно единственная, но фатальная ошибка.

Цитата ("ArtLab"):

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

Вас там семеро для того, чтобы один человек занимался и проектированием базы и программированием и установкой nginx'a? Вычеркните меня из списка кандидатов в такую команду, сделайте милость. Команда собирается не для этого, вас кто-то обманул. Или вы обманываете заказчиков о количестве народа, жаждущих покушать. Никакого понятия о разделении задач внутри команды.

Цитата ("ArtLab"):

Пожалуйста, не говорите того, в чем вы не уверены, иначе это просто очернение.

Ок, только не говорите в свою очередь, что при экономии на спичках пишутся кривые базы, это сказки про Деда Мороза.

Цитата ("ArtLab"):

Связь такая, что есть вещи более существенные, которые требуют внимания, чем оптимизации и экономии на спичках.

Опять ваши домыслы про то, что оптимальный код жрет время. Наоборот. Он меньше, лучше читается, быстрее пишется и быстрее исполняется.

Цитата ("ArtLab"):

Знаете, что на таких объемах - никто не будет экономить и доставит сервер в кластер, чем будет заниматься такими вот оптимизациями, чтобы поднять скорость загрузки страницы на 0.1 ?

Ваше пренебрежение мелочами делает из 0.1 все 5-15%. А кластер как вы знаете не такая уж дешевая штука, чтобы бесконтрольно жрать ресурсы и покупать каждый день новый сервер, когда можно было просто найти толковых кодеров.

Цитата ("trueW3C"):

Там не только echo был...там повсюду такой бред

Верно, такие конструкции используются (или использовались, я последний раз эту систему видел 2 года назад) во всех вызовах всех функций. И не только такие конструкции, там много чего интересного. К примеру, он при использовании одного модуля подгружал все, которые доставлялись в двиг. А это, извините, охотничьи спички. И как раз пример того, как привычки не экономить на мелочах вырабатывают привычку не экономить вообще. А ваш настрой, ArtLab, приводит к другой ситуации. Вместо оптимизации работы скриптов или базы, гораздо эффективнее оптимизировать саму команду разрабов.

Цитата ("Lisio"):

Теперь моя очередь смеяться як конь Вы всей командой изучаете стандарты индийского программирования? Когда всеобъемлющая оптимизация нарушала стиль и стандарты? Китай и Индия - это не всеобщие стандарты.

Вы можете смеяться сколько вашей душе угодно

Мой ответ был на это:

Цитата ("Lisio"):

Верно. Так и есть, предпочитаю анализировать чужой код, но писать своё, под свои нужды и задачи со своим стилем программирования и понимания оптимизации на всех уровнях. Поверьте, мне не важно, что вы смеетесь, ради Бога, в вопросах оптимизации мне глубоко плевать на мнение остальных по вопросу: стоит ей заниматься или нет и в какой степени.

Я говорил о том, что вы - любитель изобретать велосипед, писать все так, как "под свои нужды и задачи по своим стилем программирования".

Команда всегда работает с одним стилем программирования, если кто работает не по стандарту кодирования команды - ему обычно бьют по рукам и мягко намекают, что есть стандарт и его надо придерживаться. Если это не помогает - человека удаляют и заменяют тем, кто может и хочет работать в команде, а не ведет себя как одиночка сам себе на уме.

Цитата ("Lisio"):

Вполне понятен. Вы все еще считаете, что написание изначально быстрого кода требует больше времени. В этом ваша возможно единственная, но фатальная ошибка.

Я считаю, что оптимизации должны быть обоснованы и далеко не все имеет смысл внедрять. Вопрос к вам был именно в свете " и '. Эта, конкретно эта оптимизация и все ей подобные - бесполезная трата времени.

Цитата ("Lisio"):

Вас там семеро для того, чтобы вы один человек занимался и проектированием базы и программированием и установкой nginx'a? Вычеркните меня из списка кандидатов в такую команду, сделайте милость. Команда собирается не для этого, вас кто-то обманул. Или вы обманываете заказчиков о количестве народа, жадущих покушать. Никакого понятия о разделении задач внутри команды.

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

Я в команде выполняю роль проджект-менеджера, при этом не стесняюсь писать код, да. Поэтому могу и базу спроектировать и установить nginx, если понадобится. Что в этом плохого, не пойму? Я руковожу процессом и готов всегда встать на место любое, если это того потребует.

Цитата ("Lisio"):

Ок, только не говорите в свою очередь, что при экономии на спичках пишутся кривые базы, это сказки про Деда Мороза.

Я говорю о том, что это пустая трата времени и лучше это время потратить на что-то более существенное. Абстрагируйтесь от примера о ' и " (в данном случае различия в телодвижениях минимальны) Есть куча других примеров, когда экономия ведется на спичках, при этом для этого нужно делать телодвижения.

Цитата ("Lisio"):

Опять ваши домыслы про то, что оптимальный код жрет время. Наоборот. Он меньше, лучше читается, быстрее пишется и быстрее исполняется..

Я требую доказательств. Мои контраргументы: код на АСМе - он быстрее, пишется не факт что быстрее, но быстрее выполняется. А читается не особо, особенно если не специалист его читает.

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

Цитата ("Lisio"):

Ваше пренебрежение мелочами делает из 0.1 все 5-15%.

Откуда вы знаете? Ваши цифры высосаны из пальца.

Цитата ("Lisio"):

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

Вы говорите о том, в чем видимо не разбираетесь. Когда проект переходит на уровень миллионных посещений в день - докупить юнит в кластер - совсем копейки стоит, при этом прирост будет намного существеннее, чем переписывать код с " на ' )) Уж поверьте

Цитата ("Lisio"):

К примеру, он при использовании одного модуля подгружал все, которые доставлялись в двиг. А это, извините, охотничьи спички. И как раз пример того, как привычки не экономить на мелочах вырабатывают привычку не экономить вообще.

Это пример быдлокодерства, а не отсутствие привычки экономии.

Цитата ("Lisio"):

А ваш настрой, ArtLab, приводит к другой ситуации. Вместо оптимизации работы скриптов или базы, гораздо эффективнее оптимизировать саму команду разрабов.

И сколько команд разрабов вы оптимизировали/собрали?

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

Естественно, каждый программист из команды изначально должен понимать, что конструкции вида:

<?php

$names = array('me', 'you', 'bla-bla');


for ($i = 0; $i <= count($names); $i++) {

// do something

}

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

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

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