Дойдете до 5 тыс рублей - пишите.
Так вот альфа как раз и заявляет по этому случаю, что у них (в отличии от многих других брокеров) купленные (хотя и не поставленные) tom баксы выступают типа обеспечением (при расчете лимитов на покупку). И это хотя необычно, но легально.
Так, а в чем смысл возражать тогда? Если не понимаете.
А модель базы чем диктуется? Правильно, архитектурой. А что нельзя завязывать на форежн? Правильно, архитектуру.
В "абстрактном сферическом фреймворке в вакууме" - да.
Мы же говорили об архитектуре заточенной на конкретную задачу.
Даже писали "Правильные запросы можно создать только правильно зная задачу. Поэтому эта дилемма (прим: попытка создать правильный ORM для всего всего) в рамках общего фреймворка/цмс неразрешима. ".
Попробуем перефразировать.
Если Вы делаете приложение, которое "как-то" должно оформить запросы в базу, получив "что-то" на входе, то Вы можете реализовать джоины, прямые запросы, форежн ключи и прочее - как Вам б-г на душу положит. Nobody cares.
Если Вы делаете приложение, которое должно быстро работать и хорошо масштабироваться, то его цели будут напрямую влиять на архитектуру и на реализацию каждого конкретного запроса и тут уже абстрактным ORM, которое "как-то" оформит запросы в базу не обойдетесь. Каждую группу запросов, если не каждый запрос, Вам придется оформлять по индивидуальной схеме, в ряде случаев руководствуясь не только теорией о скорости, но и практическими тестами. Вспомните, например, для чего делают денормализацию БД - а ведь это самые первые полшага на этом пути.
Лучшее что может разрешить фреймворк в этом смысле, это создать логированный полуофициальный черный ход в обход своего встроенного ORM. Иначе в специализированных задачах он будет бесполезен.
Регулярки жрут память, по возможности обходитесь без них.
Инлайн шаблоны жрут память, по возможности обходитесь без них.
mysql_fetch_array жрет память дублируя возвращаемый массив, по возможности лучше mysql_fetch-assoc.
Память потребляемую Вы меряете неверно, используйте memory_get_peak_usage. Заодно поймете, сколько на самом деле нужно вордпрессу.
А вообще количество косяков в коде (не в стиле, в коде) такое, что возникает ощущение, что Вы это писали по какой-то книжке. Книжку в сад, возьмите любой реально распространенный, но легкий движок и посмотрите как сделано.
Вы понимаете разницу между "вшить в архитектуру foreign key" - как мы сказали... и между "использовать foreign key" - как написали Вы?
Нельзя завязывать приложение/архитектуру на джоинах и прочем. Ибо разделяй и властвуй.
Всегда должна быть возможность, при этом не сильно потеряв в производительности, работать с базовым набором данных "одиночными" выборками.
В нем понта примерно ноль на php. Если у Вас скрипт работает по 2 секунды, то инсерт делеед Вас не спасет. А если 0.02 секунды, то смысл от него?
Инсерт делеед хорош при использовании в пхп демонах, когда один и тот же мускул коннект висит по часу. Но где Вы видели это в цмс?
У нас в текущей CMS сделано проще, всё что не требует "мгновенной" реакции тупо сбрасывается в таблицу очередей, откуда потом по крону разбирается. И статистика и логи и все остальное.
Зато масштабируется фигово. При чем иногда до смешного фигово.
Не, если иннер джоин именно в разы быстрее, то можно обыграть как-то архитектуру вокруг этого, сделать нечто вроде кэширования, но нельзя вшивать это в саму архитектуру. Потому что когда Вам понадобится одну таблицу скинуть на один сервер, другую на другой, а у Вас джоины по обоим - Вы застреллитесь.
Правильные запросы можно создать только правильно зная задачу. Поэтому эта дилемма в рамках общего фреймворка/цмс неразрешима.
Из-за бабла начинается движение. А потом уже не отвертишься:) Но в целом все верно.
Эти парни не просто "изучали php исходники", а "были их авторами":)
На качество фреймворка это правда не повлияло, однако опять же - это чисто коммерческая вещь... и тем не менее в результате это стандарт-де-факто и must know - безусловно.
Одна из причин то, что count(*) более универсален, чем sql_calc. Вторая несомненно в том, что sql_calc мало кто знает:)
Однако теоретическое объяснение шустрости в принципе на поверхности.
sql_calc перебирает всю таблицу (точнее ее остатки), что бы посчитать количество записей.
В то время как count(*), при условии наличия индекса, в таблицу не полезет, он возьмет все данные непосредственно из индекса, что даст хороший результат по скорости.---------- Добавлено 05.02.2016 в 21:40 ----------
А вот это верно.
Даже если хватит сил сделать фреймворк, работа по его поддержке и развитию потребует сил в десятки раз больше. Как правило, большинство новомодных фреймворков и цмс на этом и срезаются. Вроде и хороший продукт получился, но как дело доходит до поддержки - времени у разработчиков тупо не хватает.
При падении бакса относительно чего?
Нефть упала к доллару, евро упал к доллару.
Рынок вероятно:)
Ониж агрегатор, по питеру (россия), например, всего 2 нормальных сайтах с объявлениями. И какой смысл в яндекс.недвижимости? Которая в себя тянет инфу с хз какого количества сайтов с объявлениями, в которых 90% рекламного хлама? Да еще оценки объявлениям дает неадекватные (в 80% случаях искать что-то нужно только среди объявлений с "подозрительно низкой ценой").
Ладно бы поиск там был крутой и гибкий, так ведь нет.
