Здравствуйте, SpLove, Вы писали:

SL>Я согласен с вами. Я знаком с циклом проектирования, просто думаю основная проблема различное мышление web архитекторов и архитекторов системного ПО. Вот, что нужно реализовать:
Думаю, это не основная проблема. Мне кажется, что сначала нужно построить функциональную модель программы, затем — распределить функции по сущностям, а уж потом — думать о реализации.

SL> — регистрацию пользователей;
SL> — механизм аутентификации зарегистрированных пользователей;
SL> — просмотр информации о выбранном пользователе.
Группа функций 1. "Работа с пользователями"

SL> — добавление нового изображения (загрузка на сервер);
SL> — просмотр списка всех загруженных пользователями изображений;
SL> — просмотр детальной информации о каждом изображении с возможностью оставить свой комментарий и оценить его по шкале от 1 до 5;
Группа функций 2. "Работа с изображениями"

Из приведенного Вами перечня функций можно выделить две группы:

Группа 1. "Работа с пользователями"
Группа 2. "Работа с изображениями"

Эти группы можно детализировать:

Работа с пользователями:

1) Регистрация нового пользователя.
2) Удаление зарегестрированного пользователя.
3) Аутентификация зарегестрированного пользователя.
4) Просмотр информации о зарегестрированном пользователе.
5) Редактирование информации о зарегестрированном пользователе.
6) Посылка сообщения другому зарегестрированному пользователю.
7) Просмотр сообщений, присланных зарегестрированному пользователю.
8) Удаление сообщений, присланных зарегестрированному пользователю.
9) Отсылка предупреждения зарегестрированному пользователю.
10) Просмотр предупреждений, присланных зарегестрированнолму пользователю.
11) Оценка зарегестрированного пользователя.
12) Изменение рейтинга зарегестрированного пользователя.
13) Удаление рейтинга зарегестрированного пользователя.
14) Добавить друга.
15) Удалить друга.
16) Просмотреть список друзей.
17) Посмотреть конкретного друга.
18) Попроситься кому-то в друзья.
14) И т.д. Дополните этот список.

Работа с изображениями:

1) Добавление изображения. Куда? Очевидно, в альбом.
2) Удаление изображения. Откуда? Очевидно из альбома.
3) Вывод — необходимы альбомы. Начинаем список с начала...

1) Создание нового альбома.
2) Удаление существующего альбома.
3) Назначение/изменение прав доступа к альбому.
4) Открытие существующего альбома:
а) для просмотра;
б) для модификации.
5) Добавление фотографии в альбом:
а) с компьютера пользователя;
б) из того же альбома пользователя;
в) из другого альбома пользователя;
г) из альбома другого пользователя;
д) с постороннего интернет-сайта;
е) и т.д.
6) Изменение положения фотографии в альбоме.
7) Удаление фотографии из альбома.
8) Просмотр комментариев к альбому.
9) Добавление комментария к альбому.
10) Удаление комментария из альбома.
11) Просмотр комментариев к фотографии.
12) Добавление комментария к фотографии.
13) Удаление комментарии к фотографии.
14) Оценка альбома.
15) Просмотр оценки альбома.
16) Обнуление рейтинга альбома.
17) Отказ от участия в рейтинге.
18) Оценка отдельной фотографии.
19) Просмотр оценки отдельной фотографии.
20) Обнуление рейтинга фотографии.
21) Отказ от участия в рейтинге.
22) Записать альбом в фавориты.
23) Удалить альбом из фаворитов.
24) Просмотреть список фаворитов.
25) Изменить положение альбома в фаворитах.
26) Создать подкатегорию в фаворитах.
27) Переместить или скопировать альбом в подкатегорию.
28) И т.д. Дополните этот список.

После Вашего ответа продолжим.

Здравствуйте, DerBober, Вы писали:

DB>Начинай с проектирования БД. Это главный компонент в подобных приложениях. А после и до классов доберешься.
Нет. В таких проектах главный вопрос: Сколько будет народу.
Ибо пока на него не ответишь ничего не спроектировать.
Ибо база для 100 и для 100 тысяч пользователей это совершенно разные базы. Те просто ничего общего.
Так же отдельный очень интересный вопрос: как хранить фотографии так что бы их не потерять? В базе нельзя. База тонны блобов не выдержит. Да и раздавать из базы занятие не быстрое, а раздавать нужно много и быстро.

Здравствуйте, Нахлобуч, Вы писали:

Н>

Н>$response->rowset('submenu', array('*' => 'attr'))->addRow($menuManager->getMenuForParent($submenuParentId));
Н>

ДГ>>В итоге ты только запутаешь код.
Н>Как видишь, не запутал. Более того, этот код стало проще поддерживать и тестировать.

Всё это очень красиво, очень объектно-ориентированно и концептуально очень правильно. Но к сожалению, в подавляющем большинстве веб-проектов (не отличающихся сложностью бизнес-логики) совершенно непрактично. И я здорово сомневаюсь, что твой код проще поддерживать и тестировать.

Прежде всего, по причине невозможности кеширования объектов между HTTP-запросами, и по причине отсутствия реализации Hibernate для PHP, все запросы приходится оптимизировать вручную. Раскладывать вручную оптимизированный запрос в "правильную" объектную модель — занятие для больших оригиналов. Нужны очень веские причины, чтобы заниматься подобным извращением. Я уже писал — таковые причины у меня нашлись только один раз за последние 5 лет. Подавляющее большинство сайтов не настолько сложны, и в них вполне достаточно описанного мною модульного подхода, в котором каждая точка входа — атомарная операция, вполне читабельная и легко сопровождаемая. Декомпозировать такие скрипты дальше не имеет смысла.

Далее. Все результаты SQL-запросов где-то используются, верно? Так случилось, что большинство результатов просто отдаётся клиенту (исключения — какие-то проверки перед модификацией базы). А теперь смотри: результаты используются в XSLT-преобразовании. Выполнение XSLT-скриптов я по возможности (в зависимости от значения USER AGENT) отдаю на откуп клиенту, чтобы уменьшить нагрузку на сервер и трафик. И поэтому я должен очень внимательно подходить к тому, какие столбцы я отдаю в XML-ответе. Юзеры, админы и незалогинившиеся посетители очень часто получают совершенно разные наборы столбцов. В результате я вынужден либо генерировать SQL-запрос динамически, либо дублировать его в разных вариациях для разных точек входа и разных юзеров/админов/прочих. И как по мне, гораздо проще отслеживать все эти ньюансы и зависимости в контексте одного скрипта (где они как на ладони), чем плодить тьму методов (или параметризованные методы):

$menuManager->getMenuForUser(...);
$menuManager->getMenuForAdmin(...);
$menuManager->getMenuForLoggedOut(...);

С предложенным тобой делегированием сам скрипт index.php становится неприятным промежуточным звеном между index.xsl и сильно, но неочевидно связанных с ним методов каких-то объектов-менеджеров. А уж если ты попытаешься вынести генерацию, скажем, списка пользователей по сложному условию (или любой другой нетривиальный SQL-запрос) из search.php (где он выглядит вполне уместно) в какой-нибудь $userManager, то в итоге получишь совершенно расчудесный вызов типа $userManager->getUsersByConditionForAdmin($twenty, $filter, $parameters, $which, $are, $impossible, $to, $remember, $and, $very, $hard, $to, $specify, $without, $mistake). Ну и нахрена козе боян?

Короче говоря, я просто использую другой способ декомпозиции — модульный, а не объектный. И на простых и средней сложности проектах, в условиях налагаемых языком PHP ограничений, этот способ гораздо проще и эффективнее объектов. У меня было предостаточно времени на эксперименты — могу честно сказать, что данный подход выстрадан на не одном десятке проектов (включая контент-сайты, службы знакомств с форумумами, блогами и интернет-магазинами — типовые задачи, и в целом далеко не самые тривиальные). И я готов поспорить, что твои ООП-заморочки (так называемые "упрощения") приведут только к усложнению кода и существенному снижению его эффективности.

Не надо фанатично тянуть ООП за уши куда надо и куда не надо — это не панацея. Универсальных методологий не бывает.

Автор: Дм.Григорьев
Дата: 02.07.07

Здравствуйте, Нахлобуч, Вы писали:

Н>6000 WMR...

О, у меня ещё останутся деньги по экскурсиям покататься! Я как раз собирался на этих выходных в Абхазию... (Это так, к слову. )

Н>...и ASP.NET 2.0 с моей стороны (с использованием всяких библиотек, разумеется)

Не катит. ASP вполне себе объектный. Повторяю в десятый раз (уж извини — походу опять для тупых ): мой модульный подход — результат эволюции моего именно PHP-стиля. (На Java я, знаешь ли, тоже всё на объектах рисую... хотя прочтение флейма, на который я привёл ссылку ниже, вызвало определённую задумчивость.) И изначально в ветке был вопрос именно по PHP. И тебе требуется доказать, что именно на PHP со всеми его ограничениями ты сделаешь на объектах во всех смыслах лучше, чем я без объектов.

По библиотекам — разговор отдельный. Я как бы против, но это обсуждаемо.

Н>Что мы друг другу докажем килобайтами кода? Что тебе или мне писать меньше пришлось? И что с того?

IT неоднократно утверждал, что объём кода — это наиболее простой и достоверный показатель его сложности. (Кстати, про то, что при необходимости ООП идёт лесом

Автор: IT
Дата: 12.12.03

, он тоже упоминал. )

Н>И пишу я с комментариями всегда.

Комментарии перед сравнением вырежем. И вообще, нормальный код (тем более для такой тривиальной задачи) должен быть самодокументирующимся. (Я даже готов переименовать свои $db->qrow() и $db->qarray() в $db->queryRow() и $db->queryArrayOfRows() не взирая на килобайты! ).

ДГ>>4. Сравниваем объем изменений в коде
Н>Опять же -- что докажем-то?

Сложность изменений. Ну или я жду твоих предложений.

ДГ>>Поскольку ты доказываешь, что ООП хорош в любой ситуации, то для опровержения необходимо привести хотя бы один пример задачи, с которой мой подход справляется лучше.
Н>Критерии оценки "лучше" какие? Уж не объем ли кода?

Объём кода как показатель сложности, и скорость работы (кстати, по последнему критерю сравнивать ASP и PHP опять же некорректно).

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Не катит.

Ну тады звиняйте. "Языками не владею, ваше величество!" ©

Посоветуйте как правильно спроектровать каркас сервиса обмена графическими изображениями. Трудно представить архитектуру web-приложения, после разработки windows-приложений. Если бы под windows начал бы так(в скобках классы): Есть страница(Page), она включает навигацию (MainMenu, HeaderMenu, Navigation) и содержимое(Content), которое включает коллекцию фотографий(FotoCollection) и т.д. С этим никаких проблем, но как выглядит архитектура на php5 представляю смутно. Помогите разобраться, также буду рад примерам удачных архитектур с паттернами проектирования и кодирования

Здравствуйте, SpLove,

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

Возможно, эти операции станут очевидными после того, как Вы распишите несколько вариантов использования (use cases).

После этого можно будет говорить об архитектуре.

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, SpLove,

КЛ>Полагаю, что начинать проектирование нужно не с объектов и классов, а с операций, которые будут доступны пользователям. Опишите, какие действия может совершать пользователь при использовании портала. Так же укажите и действия портала, которые важны для пользователя.

КЛ>Возможно, эти операции станут очевидными после того, как Вы распишите несколько вариантов использования (use cases).

КЛ>После этого можно будет говорить об архитектуре.

Я согласен с вами. Я знаком с циклом проектирования, просто думаю основная проблема различное мышление web архитекторов и архитекторов системного ПО. Вот, что нужно реализовать:
— регистрацию пользователей;
— механизм аутентификации зарегистрированных пользователей;
— добавление нового изображения (загрузка на сервер);
— просмотр списка всех загруженных пользователями изображений;
— просмотр детальной информации о каждом изображении с возможностью оставить свой комментарий и оценить его по шкале от 1 до 5;
— просмотр информации о выбранном пользователе.

Здравствуйте, SpLove, Вы писали:

Скрлько народу на сервисе плинируется?

Здравствуйте, SpLove, Вы писали:

SL>Посоветуйте как правильно спроектровать каркас сервиса обмена графическими изображениями. Трудно представить архитектуру web-приложения, после разработки windows-приложений.

Начинай с проектирования БД. Это главный компонент в подобных приложениях. А после и до классов доберешься.

Здравствуйте, WolfHound, Вы писали:

DB>>Начинай с проектирования БД. Это главный компонент в подобных приложениях. А после и до классов доберешься.
WH>Нет. В таких проектах главный вопрос: Сколько будет народу.
WH>Ибо пока на него не ответишь ничего не спроектировать.
WH>Ибо база для 100 и для 100 тысяч пользователей это совершенно разные базы. Те просто ничего общего.

Ну ну. Пока вы наберете первую тысячу пользователей все приложение успеете несколько раз переделать. Getting Real / Scale Later А преждевременная оптимизация, как известно, есть корень всех бед.
А ежели переделываете уже раскрученный сервис (фликер например) с гарантированными тысячами/миллионами пользователей, то таких вопросов возникать не должно.

Здравствуйте, DerBober, Вы писали:

DB>Ну ну. Пока вы наберете первую тысячу пользователей все приложение успеете несколько раз переделать.
Это зависит от того насколько хорошо работают маркетойды. И сколько денег есть на рекламу.
Если маркетойды хорошие и деньги на рекламу есть то десятки тысяч песетителей может быть в день запуска.
Но маркетойды должны быть очень хорошими.

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

DB>А преждевременная оптимизация, как известно, есть корень всех бед.
Фраза правильная только не в тему.

Короче пока не ответишь на вопрос: Сколько будет народу? (Нужен прогноз по крайней мере на год.)
К разработке такой системы даже не подходи.

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

Здравствуйте, WolfHound, Вы писали:

DB>>Ну ну. Пока вы наберете первую тысячу пользователей все приложение успеете несколько раз переделать.
WH>Это зависит от того насколько хорошо работают маркетойды. И сколько денег есть на рекламу.
WH>Если маркетойды хорошие и деньги на рекламу есть то десятки тысяч песетителей может быть в день запуска.
WH>Но маркетойды должны быть очень хорошими.

Ага. И маркетологи золотые и деньги есть и вообще все шоколадно. Непонятно только откуда при таких раскладах подобные вопросы у разработчиков возникают. (Не хочу никого обидеть. Честнослово.)

WH>Короче пока не ответишь на вопрос: Сколько будет народу? (Нужен прогноз по крайней мере на год.)
WH>К разработке такой системы даже не подходи.

Никто не спорит с важностью вопроса о предельных нагрузках. Но по любому в основе будет БД. Даже если сами фотки лежат в ФС. Когда оптимизировать сервис под большие нагрузки это уже их проблема. Можно и сразу если бюджет позволяет.

Здравствуйте, SpLove,

Прежде всего, тебе следует свыкнуться с мыслью, что каждая страница сайта — изолированный скрипт. То есть, нет единой точки входа в приложение; каждая страница — отдельная точка входа. А учитывая тот печальный факт, что PHP — это просто скриптовый язык (запустился по HTTP-запросу — отработал — завершился, никаких фраерских выпендров типа резидентных многопоточных приложений и in-memory caches), то вся работа по инициализации приложения (коннект к базе, доставание данных о залогиненном пользователе из сохранённой сессии и проверке актуальности этого пользователя по базе, создание дерева объектов буде таковое использоваться) выполняется при каждом запуске скрипта, т.е. при каждом HTTP-запросе. Уже приятно, не так ли?



Для меня задача разработки сайтов на PHP всегда состоит из двух взаимосвязанных частей:

1. Разработка БД. (Реверанс в сторону WolfHound: с учётом требований о нагрузке, разумеется, хотя писать на PHP сервис под высокую нагрузку — это занятие для истынных ивзращенцев. Как раз вчера я в порядке самообразования проштудировал старый флейм stateful vs stateless за 2003 год... и подумал между делом: вот бы IT порадовался, случись ему писать на PHP... полный б#$%^ь stateless... Шучу, шучу. )

2. Определения множества HTTP-запросов пользователя, и разработка под каждый запрос своего отдельного скрипта — отдельной точки входа. Общий код инициализации приложения выносится в include-файл.



Никакой объектной модели предметной области нет. Каждый скрипт — именно скрипт, тупой и плоский. С голыми SQL-запросы. ООП я использовал только для написания удобных врапперов для парсинга HTTP-запросов, доступа к базе, генерации HTTP-ответов, ну и прочие utilities (типа поддержки блокировок). Вот типичный пример скрипта и генерируемого им ответа:

index.php

<?php
require_once(dirname(__FILE__) . '/_php/include_user.php');

$pageId = (int)$request->get('page');
if (!$pageId) {
    $pageId = 1;
}
$r = $db->qrow("select * from {PREFIX}pages where id=?", array(0 => $pageId));
if (!$r) {
    require_once(dirname(__FILE__) . "/404.php");
    die();
}

$response->rowset('page', array('text' => 'xhtml'))->addRow($r);
$submenuParentId = $r['parentid'] ? $r['parentid'] : $r['id'];
$response->rowset('submenu', array('*' => 'attr'))->addDBRowset($db->query(
        "select id, uri, menutitle from {PREFIX}pages where parentid=? order by sortorder", 
        array(0 => $submenuParentId)));

//$response->outputXML();
$response->outputHTML($config['design_path'] . "index.xsl");
?>

Вывод, если раскомментить outputXML() вместо outputHTML():

<?xml version="1.0" encoding="UTF-8"?>
<response status="ok">
  <rootUrl>http://localhost/freep/trunk/www/</rootUrl>
  <requestUri></requestUri>
  <requestUriPage>?page=</requestUriPage>
  <mainmenu>
    <r id="1" menutitle="Главная"/>
    <r id="2" uri="search.php" menutitle="Поиск"/>
    <r id="3" menutitle="Помощь"/>
  </mainmenu>
  <page>
    <r>
      <id>1</id>
      <sortorder>1</sortorder>
      <menutitle>Главная</menutitle>
      <pagetitle>Главная</pagetitle>
      <text xhtml="1">
        <p>Типа контент для страницы <strong>Главная</strong>.</p>
      </text>
    </r>
  </page>
  <submenu/>
  <request>
    <PHPSESSID>9o0llcuo766hmntstq7nguite2</PHPSESSID>
  </request>
</response>

Метод outputHTML() просто применяет XSLT к этому XML-выводу. Очень удобно, между прочим.

Единственные task-specific объекты, которые у меня водились достаточно часто (когда выпадала возможность писать под транзакционный MySQL/InnoDB, а не MySQL/MyISAM), это функторы-транзакции, отрабатывающие внутри кода, перезапускающего транзакцию в случае deadlock (по одному функтору на точку входа, плюс механизм вызова функторов-"подпрограмм" с какими-то общими для нескольких скриптов операциями).



Объектную модель предметной области я создавал только один раз, когда сложность взаимосвязей между сущностями вышла из-под контроля. Нарисовал простенький ORM... (Ну очень простенький... не так давно в форуме "Веб-программирование" кто-то спрашивал про ORM на PHP, но мне своей кустарщиной стыдно было делиться... да и какой к чёрту ORM, если кеши пропадают при завершении скрипта?) И честно предупредил заказчика, чтобы он готовился покупать выделенный сервер и переписывать всё на JBoss.

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

Здравствуйте, DerBober, Вы писали:

DB>Ага. И маркетологи золотые и деньги есть и вообще все шоколадно. Непонятно только откуда при таких раскладах подобные вопросы у разработчиков возникают. (Не хочу никого обидеть. Честнослово.)
Так у меня и не возникает.

DB>Никто не спорит с важностью вопроса о предельных нагрузках. Но по любому в основе будет БД. Даже если сами фотки лежат в ФС. Когда оптимизировать сервис под большие нагрузки это уже их проблема. Можно и сразу если бюджет позволяет.
Тут проблема в том что нагрузки бывают разные. И БД тоже.
Есть нагрузки которые держит MySQL, есть нагрузки для которых нужен Oracle, а есть нагрузки для которых нужен MySQL.
Парадокс?
Оказывается нет.
В третьем случае просто делается своя БД под конкретную задачу при реализации который другие БД используются лишь как тупые таблички с индексами и ничего кроме плоских селектов и примитивных апдейтов по ним не делают. Плюс еще несколько фокусов.
Таким образом какая там БД с диском возится в очень широких приделах барабану.
Он задачка мягко говоря не тривиальная. Без особой нужды дешевле взять Oracle.

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

ЗЫ Большое железо — лохотрон. Кластеры рулят.

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>index.php

ДГ>

ДГ>$r = $db->qrow("select * from {PREFIX}pages where id=?", array(0 => $pageId));
ДГ>        "select id, uri, menutitle from {PREFIX}pages where parentid=? order by sortorder", 
ДГ>

Я прошу прощения, но что, в Пыхпыхе только так и делают, да? То есть прямо вот так вот SQL зашивают в код?

Здравствуйте, Нахлобуч, Вы писали:

Н>Я прошу прощения, но что, в Пыхпыхе только так и делают, да? То есть прямо вот так вот SQL зашивают в код?

Гы, а ты предлагаешь его из ресурсов грузить?
Всё определяется сложностью проекта. Мой подход, чрезвычайно удобный на небольших и средних проектах, на сложных не сработает (о чём я также отчитался).

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Всё определяется сложностью проекта. Мой подход, чрезвычайно удобный на небольших и средних проектах, на сложных не сработает (о чём я также отчитался).

С этим я и не спорю. Но хранить SQL в коде совсем уж некошерно. Хотя бы и в ресурсы вынести -- всяко лучше будет.

Здравствуйте, Нахлобуч, Вы писали:

ДГ>>Всё определяется сложностью проекта. Мой подход, чрезвычайно удобный на небольших и средних проектах, на сложных не сработает (о чём я также отчитался).
Н>С этим я и не спорю. Но хранить SQL в коде совсем уж некошерно. Хотя бы и в ресурсы вынести -- всяко лучше будет.

Чем же это лучше? Ты увеличиваешь сложность на пустом месте, разбивая вполне простой алгоритм скрипта на несколько слоёв, причём сильно связанных. В итоге ты только запутаешь код. Или по-твоему, часто возникает потребность менять крохотный кусочек единого алгоритма (текст SQL-запроса) без изменений в остальных частях (PHP-код, в т.ч. обработка result set)? В общем, в данном случае ты говоришь ерунду.

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Чем же это лучше? Ты увеличиваешь сложность на пустом месте, разбивая вполне простой алгоритм скрипта на несколько слоёв, причём сильно связанных.

Сложность никто не увеличивал. Я ее просто перераспределил, вытащив не относящиеся к делу куски из одного модуля в другой. И понятность от этого ничуть не уменьшилась: заменив

$response->rowset('submenu', array('*' => 'attr'))->addDBRowset($db->query(
    "select id, uri, menutitle from {PREFIX}pages where parentid=? order by sortorder", 
    array(0 => $submenuParentId)));

на (PHP не владею, псевдокод)

$response->rowset('submenu', array('*' => 'attr'))->addRow($menuManager->getMenuForParent($submenuParentId));

я сделал только лучше.

ДГ>В итоге ты только запутаешь код.

Как видишь, не запутал. Более того, этот код стало проще поддерживать и тестировать.

ДГ>Или по-твоему, часто возникает потребность менять крохотный кусочек единого алгоритма (текст SQL-запроса) без изменений в остальных частях (PHP-код, в т.ч. обработка result set)?

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

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Прежде всего, по причине невозможности кеширования объектов между HTTP-запросами, и по причине отсутствия реализации Hibernate для PHP, все запросы приходится оптимизировать вручную.

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

ДГ>Раскладывать вручную оптимизированный запрос в "правильную" объектную модель — занятие для больших оригиналов. Нужны очень веские причины, чтобы заниматься подобным извращением.

Частично соглашусь. Вручную гидрировать "правильную" объектную модель и правда занятие не из приятных. Однако же в случае, когда классы Domain Model представляют собой просто DTO на стероидах (чего достаточно для простых приложений), делать это, по-моему, не так и сложно.

ДГ>Далее. Все результаты SQL-запросов где-то используются, верно? Так случилось, что большинство результатов просто отдаётся клиенту (исключения — какие-то проверки перед модификацией базы). А теперь смотри: результаты используются в XSLT-преобразовании.

Сам с таким подходом не сталкивался, но сдается мне, что при более-менее сложной верстке этот XSLT будет феерически объемным. Плюс в HTML редакторе его так просто и не посмотришь.

$menuManager->getMenuForUser(...);
$menuManager->getMenuForAdmin(...);
$menuManager->getMenuForLoggedOut(...);

Если я правильно понял логику, то MenuManager получается очень перегруженным и у него образуется слишком большая зона ответственности — и получение объектов из БД, и разруливание вопросов с полномочиями. А сие не есть правильно .

Кроме того, вот это:

ДГ>И поэтому я должен очень внимательно подходить к тому, какие столбцы я отдаю в XML-ответе. Юзеры, админы и незалогинившиеся посетители очень часто получают совершенно разные наборы столбцов. В результате я вынужден либо генерировать SQL-запрос динамически, либо дублировать его в разных вариациях для разных точек входа и разных юзеров/админов/прочих.

тоже смущает. Насколько я могу понять из приведенного тобой выше по ветке кода (типа, "select id, uri, menutitle from {PREFIX}pages where parentid=? order by sortorder"), ты очень сильно завязываешься на имена столбцов — они у тебя есть и в тексте запроса, и во всяких индексаторах, и в XSLT. По мне, так это дюже нехорошо.

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

Получается, что для упрощения своей же жизни все вопросы отображения и сокрытия той или иной информации должны быть решены на уровне View'а (если говорми про MVP/MVC). Но тогда выходит, что либо придется использовать какой-нибудь шаблонизатор (из оных для PHP знаю только Smarty), либо делать все XSLT-преобразования на сервере.

ДГ>С предложенным тобой делегированием сам скрипт index.php становится неприятным промежуточным звеном между index.xsl и сильно, но неочевидно связанных с ним методов каких-то объектов-менеджеров.

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

ДГ>А уж если ты попытаешься вынести генерацию, скажем, списка пользователей по сложному условию (или любой другой нетривиальный SQL-запрос) из search.php (где он выглядит вполне уместно) в какой-нибудь $userManager, то в итоге получишь совершенно расчудесный вызов типа $userManager->getUsersByConditionForAdmin($twenty, $filter, $parameters, $which, $are, $impossible, $to, $remember, $and, $very, $hard, $to, $specify, $without, $mistake). Ну и нахрена козе боян?

Вот с этим соглашусь -- сам для себя никак не могу толком сформулировать подход решения этой проблемы. Получается либо Query By Example, либо класс-генератор запросов (строго типизированный) либо да, такой вот огромный метод.

ДГ>Короче говоря, я просто использую другой способ декомпозиции — модульный, а не объектный. И на простых и средней сложности проектах, в условиях налагаемых языком PHP ограничений, этот способ гораздо проще и эффективнее объектов.

Быть может. Насчет эффективности только я сильно не согласен. Разницы между 0.05 секунды и 0.5 секунды (такой оверхед надо еще постараться получить) пользователь вряд ли заметит.

ДГ>У меня было предостаточно времени на эксперименты — могу честно сказать, что данный подход выстрадан на не одном десятке проектов (включая контент-сайты, службы знакомств с форумумами, блогами и интернет-магазинами — типовые задачи, и в целом далеко не самые тривиальные).

Ну неужто в интернет-магазинах и службах знакомств ты текст запроса тоже в коде писал?

ДГ>И я готов поспорить, что твои ООП-заморочки (так называемые "упрощения") приведут только к усложнению кода и существенному снижению его эффективности.

Эффективность -- это в смысле быстродействие? А как же преждевременная оптимизация -- корень всех зол?

Здравствуйте, WolfHound, Вы писали:

WH>ЗЫ Большое железо — лохотрон. Кластеры рулят.
http://tpc.org

P. S.
Задачи бывают разные, есть задачи, где кластера сливают со свистом, OLTP, например.

Здравствуйте, Нахлобуч, Вы писали:

Н>Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>>Прежде всего, по причине невозможности кеширования объектов между HTTP-запросами, и по причине отсутствия реализации Hibernate для PHP, все запросы приходится оптимизировать вручную.

Н>Во-первых, кэширование можно и самому (если уж очень припрет) сделать.

Как? Что-то мне подсказывает, что ты имеешь в виду совершенно другое кеширование, и вообще читаешь мои посты через строчку.

ДГ>>Раскладывать вручную оптимизированный запрос в "правильную" объектную модель — занятие для больших оригиналов. Нужны очень веские причины, чтобы заниматься подобным извращением.

Н>Частично соглашусь. Вручную гидрировать "правильную" объектную модель и правда занятие не из приятных. Однако же в случае, когда классы Domain Model представляют собой просто DTO на стероидах (чего достаточно для простых приложений), делать это, по-моему, не так и сложно.

Гы. "Просто DTO"? "Не так уж и сложно"? Тебе никогда, видать, не приходилось поднимать несколько объектов одним SQL-запросом из нескольких сджойненных таблиц (чтобы не плодить отдельныё SQL-запрос на каждую фигню) — именно это я и имел в виду.

ДГ>>Далее. Все результаты SQL-запросов где-то используются, верно? Так случилось, что большинство результатов просто отдаётся клиенту (исключения — какие-то проверки перед модификацией базы). А теперь смотри: результаты используются в XSLT-преобразовании.

Н>Сам с таким подходом не сталкивался, но сдается мне, что при более-менее сложной верстке этот XSLT будет феерически объемным.

Неправильно тебе сдаётся.

Н>Если я правильно понял логику, то MenuManager получается очень перегруженным и у него образуется слишком большая зона ответственности — и получение объектов из БД, и разруливание вопросов с полномочиями. А сие не есть правильно .

Ага, вот и я о чём.

Н>ты очень сильно завязываешься на имена столбцов — они у тебя есть и в тексте запроса, и во всяких индексаторах, и в XSLT. По мне, так это дюже нехорошо.

Гы, а ты очень сильно завяжешься на имена полей объектов. Те же яйца, только в профиль, да ещё и коду будет в десять раз больше.

Н>Если же использовать какие-никакие классы-DTO, то в общем случае получается, что для разных типов пользователей (админы, простые смертные и т.д.) требуются разные DTO с разным набором полей. Получаем экспоненциальный рост количества классов.

Н>Получается, что для упрощения своей же жизни все вопросы отображения и сокрытия той или иной информации должны быть решены на уровне View'а (если говорми про MVP/MVC). Но тогда выходит, что либо придется использовать какой-нибудь шаблонизатор (из оных для PHP знаю только Smarty), либо делать все XSLT-преобразования на сервере.

Вах, как всё стало просто!

Засунь свой Smarty куда подальше. Сложную вёрстку (и редизайн) на нём сделать гораздо труднее, чем на XSLT. И кстати, ООП-модель предметной области к Smarty прикручивается также криво, как и к XSLT. PHP вообще под ООП не заточен.

И ещё раз повторяю для тупых — XSLT на клиент выносится из соображений производительности. При этом код серверной части менятся минимально (к вопросу о лёгкости сопровождения).

Н>Разницы между 0.05 секунды и 0.5 секунды (такой оверхед надо еще постараться получить) пользователь вряд ли заметит.

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

Н>Ну неужто в интернет-магазинах и службах знакомств ты текст запроса тоже в коде писал?

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

ДГ>>И я готов поспорить, что твои ООП-заморочки (так называемые "упрощения") приведут только к усложнению кода и существенному снижению его эффективности.

Н>Эффективность -- это в смысле быстродействие? А как же преждевременная оптимизация -- корень всех зол?

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

Здравствуйте, IB, Вы писали:

IB>Задачи бывают разные, есть задачи, где кластера сливают со свистом, OLTP, например.
Ты про это?
http://tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all&version=5&currencyID=0
Так там вего один кластер. Сделаный в 2004ом... причем это самая быстрая система сделаная в 2004ом...

Кстати, а как большое железо решает задачу: Клиенты не должны узнать что в одном из датацентров выключили свет/порвали сеть/итп...
Как эту задачу решить кластером я представляю. А вот как с этим справится большое железо нет.

Здравствуйте, Дм.Григорьев, Вы писали:

Ну вот и хамство началось.

ДГ>Как? Что-то мне подсказывает, что ты имеешь в виду совершенно другое кеширование, и вообще читаешь мои посты через строчку.

Я имею в виду кэширование, во-первых, результатов отработки PHP (сгенерированных страниц), а во-вторых, бизнес-объекты -- есть же в PHP какие-то решения (на память только memcached приходит).

ДГ>Гы. "Просто DTO"? "Не так уж и сложно"? Тебе никогда, видать, не приходилось поднимать несколько объектов одним SQL-запросом из нескольких сджойненных таблиц (чтобы не плодить отдельныё SQL-запрос на каждую фигню) — именно это я и имел в виду.

Приходилось. Не вижу, где тут проблема. Разработать стиль именования столбцов и выдирать данные. Получается эдакий легковесный ORM/RSM.

ДГ>Неправильно тебе сдаётся.

Хорошо.

ДГ>Гы, а ты очень сильно завяжешься на имена полей объектов. Те же яйца, только в профиль, да ещё и коду будет в десять раз больше.

Испорчен я компилируемыми языками со строгой типизацией, знаешь ли

ДГ>Вах, как всё стало просто!

ДГ>Засунь свой Smarty куда подальше. Сложную вёрстку (и редизайн) на нём сделать гораздо труднее, чем на XSLT. И кстати, ООП-модель предметной области к Smarty прикручивается также криво, как и к XSLT. PHP вообще под ООП не заточен.

Засовывать ничего никуда не буду. Показал бы пример такого XSLT, чтоб было с чем сравнить.

ДГ>И ещё раз повторяю для тупых — XSLT на клиент выносится из соображений производительности. При этом код серверной части менятся минимально (к вопросу о лёгкости сопровождения).

Обороты сбавь. Код состояния HTTP 304 знаком?

ДГ>Оверхед в 10 раз тебе не существенен? Вот на этом месте спор можно смело заканчивать. При хорошей нагрузке твои ООП-творения благополучно ляжут.

Я не говорил, что несущественен. Ты его получи сначала, оверхед такой.

ДГ>Повторяю для тупых — у меня было достаточно проектов, чтобы наэкспериментироваться и выработать подход. Я не с бухты-барахты стал писать так, как пишу. Некоторые сайты мне пришлось переписывать с "правильных" моделей на работающие и держащие нагрузку. А ты либо обыкновенный теоретик без опыта, либо не писал на PHP ничего серьёзного (т.е. опять же без опыта).



Я в самом начале дискуссии написал, что PHP не знаю. Пишу на ASP.NET.

К тому же, у меня вызывает большие сомнения необходимость переписывания сайтов с "правильных моделей на работаюшие" -- тебе профайлер сказал, что производительность теряется именно из-за той самой "правильной" архитектуры?

Здравствуйте, Нахлобуч,

Общаться с упёртыми теоретиками — гиблое дело. Надоело. Предлагаю пари, скажем на 15000 WMR (или 500 WMZ; в общем, сколько тебе не жалко ).

1. Берём какую-нибудь простенькую задачу (скажем, простенький форум без наворотов) и делаем её оба. Ты на объектной модели, я на своих модулях. На PHP5, разумеется.
2. Сравниваем объём получившегося кода в килобайтах (пишем без комментариев), понятность кода (не экономим на именах переменных и методов), выполняем нагрузочное тестирование. В качестве жюри для оценики субъективных вещей (типа понятности кода) предлагаю привлечь членов RSDN Team (надеюсь, не откажутся).
3. Затем придумываем простенькую задачу на расширение фукнциональности (добавление какой-либо одной фичи) и реализуем её.
4. Сравниваем объем изменений в коде (можно, например, банально сравнить объём diff-ов svn) и прочие характеристики (жду предложений).

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

Чтобы никто из нас не попытался съехать с базара, предлагаю с самого начала скидывать ставки на WM-кошелёк жюри, и установить максимальный срок выполнения заданий, по истечении которого не представивший решение считается проигравшим. Поскольку делать мы будем в свободное от работы время, срок должен быть достаточно большим. Скажем, пара месяцев на исходное задание (там работы на неделю вечерами; такой большой срок — это чтобы не было никаких отмазок типа "вот, срочная работа привалила").

Ну что, рискнёшь?

Здравствуйте, Нахлобуч, Вы писали:

ДГ>>Гы, а ты очень сильно завяжешься на имена полей объектов. Те же яйца, только в профиль, да ещё и коду будет в десять раз больше.
Н>Испорчен я компилируемыми языками со строгой типизацией, знаешь ли
Н>Я в самом начале дискуссии написал, что PHP не знаю. Пишу на ASP.NET.

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

ДГ>>Засунь свой Smarty куда подальше. Сложную вёрстку (и редизайн) на нём сделать гораздо труднее, чем на XSLT. И кстати, ООП-модель предметной области к Smarty прикручивается также криво, как и к XSLT. PHP вообще под ООП не заточен.
Н>Засовывать ничего никуда не буду. Показал бы пример такого XSLT, чтоб было с чем сравнить.

Приведи код на Smarty, я приведу аналогичный на XSLT.

ДГ>>И ещё раз повторяю для тупых — XSLT на клиент выносится из соображений производительности. При этом код серверной части менятся минимально (к вопросу о лёгкости сопровождения).
Н>Обороты сбавь. Код состояния HTTP 304 знаком?

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

ДГ>>Оверхед в 10 раз тебе не существенен? Вот на этом месте спор можно смело заканчивать. При хорошей нагрузке твои ООП-творения благополучно ляжут.
Н>Я не говорил, что несущественен. Ты его получи сначала, оверхед такой.

Это были твои слова — с 0.05 сек до 0.5 сек.

Н>К тому же, у меня вызывает большие сомнения необходимость переписывания сайтов с "правильных моделей на работаюшие" -- тебе профайлер сказал, что производительность теряется именно из-за той самой "правильной" архитектуры?

Я замерял суммарное время выполнения скриптов. Самопальное профилирование, в общем.

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Общаться с упёртыми теоретиками — гиблое дело. Надоело. Предлагаю пари, скажем на 15000 WMR (или 500 WMZ; в общем, сколько тебе не жалко ).

Да лехко 6000 WMR...

ДГ>1. Берём какую-нибудь простенькую задачу (скажем, простенький форум без наворотов) и делаем её оба. Ты на объектной модели, я на своих модулях. На PHP5, разумеется.

...и ASP.NET 2.0 с моей стороны (с использованием всяких библиотек, разумеется)

ДГ>2. Сравниваем объём получившегося кода в килобайтах (пишем без комментариев),

Что мы друг другу докажем килобайтами кода? Что тебе или мне писать меньше пришлось? И что с того?
И пишу я с комментариями всегда.

ДГ>понятность кода (не экономим на именах переменных и методов),

Ну это, предположим, можно кое-как, но оценить.

ДГ>4. Сравниваем объем изменений в коде (можно, например, банально сравнить объём diff-ов svn) и прочие характеристики (жду предложений).

Опять же -- что докажем-то?

ДГ>Поскольку ты доказываешь, что ООП хорош в любой ситуации, то для опровержения необходимо привести хотя бы один пример задачи, с которой мой подход справляется лучше.

Критерии оценки "лучше" какие? Уж не объем ли кода?

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Вот-вот. Ты, парень, несколько не в теме. Я уже устал повторять, что предлагаю решения для совершенно определённого класс задач и совершенно определённых средств разработки. А ты мне тут теорию впариваешь.

Я "впариваю" свои соображения и свое видение проблемы. Можешь не соглашаться -- дело твое. Хамить только не надо.

ДГ>На форумах, где контент постоянно меняется, от этого кода толку мало. И вынос XSLT на клиента добавляет скорости независимо от кеша страниц. Вполне устоявшаяся практика, между прочим.

Это как же он добавляет скорости? Одно дело поднять из кэша сохраненную страницу, и совсем другое -- заново напялить на XML целое XSLT-преобразование.

ДГ>Это были твои слова — с 0.05 сек до 0.5 сек.

Не искажай. Мои слова были:

Разницы между 0.05 секунды и 0.5 секунды (такой оверхед надо еще постараться получить) пользователь вряд ли заметит.

ДГ>Я замерял суммарное время выполнения скриптов. Самопальное профилирование, в общем.

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

Здравствуйте, Нахлобуч, Вы писали:

Н>Хамить только не надо.

Ладно, извини.

Н>Это как же он добавляет скорости? Одно дело поднять из кэша сохраненную страницу, и совсем другое -- заново напялить на XML целое XSLT-преобразование.

Если преобразование выполняется на клиенте, с сервера нагрузка снимается — сервер просто отдаёт XSLT-файлы, которые на клиенте кстати ещё и кешируются. Так что в итоге, сервер избавляется от работы по генерации страниц, а учитывая компактный объём моих XML-ответов, ещё и трафик снижается донельзя.

ДГ>>Это были твои слова — с 0.05 сек до 0.5 сек.
Н>Не искажай. Мои слова были:
Н>

Н>Разницы между 0.05 секунды и 0.5 секунды (такой оверхед надо еще постараться получить) пользователь вряд ли заметит.

Ээээ... Я вообще-то изначально делал упор на высокую посещаемость. При хорошей нагрузке разница в 10 раз — это серьёзный повод для раздумий.

ДГ>>Я замерял суммарное время выполнения скриптов. Самопальное профилирование, в общем.

Н>Брависсимо, что я могу сказать. И откуда же такая оголтелая уверенность в том, что своим переписыванием ты чудесным образом увеличил скорость работы сайта? Быть может, пооптимизируй ты запросы -- и все сравнялось бы.

Уверенность оттуда, что я проводил замеры в процессе рефакторинга. Собственно, я и занимался оптимизацией запросов (для скорости) — а заодно упрощал код (для удобства), убирая всю эту громоздкую объектную инфраструктуру. Говорю же — я пробовал и так, и эдак. Ты сам согласился, что инкапсулировать сложные параметризованные запросы в методы с двадцатью параметрами неудобно. А если вгонять выборку нескольких объектов в один SQL-запрос, подобные ситуации будут возникать на каждом шагу — пусть не с двадцатью параметрами, а с двумя, но всё равно искать концы неудобно.

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Ээээ... Я вообще-то изначально делал упор на высокую посещаемость. При хорошей нагрузке разница в 10 раз — это серьёзный повод для раздумий.

Да ну ты получи такую разницу сначала. Чтоб при прочих равных условиях (SQL-запросы, БД, индексы) код, написанный в твоем стиле и его ОО-эквивалент выполнялись с разницей на порядок -- это надо сильно постараться.

ДГ>Уверенность оттуда, что я проводил замеры в процессе рефакторинга. Собственно, я и занимался оптимизацией запросов (для скорости) — а заодно упрощал код (для удобства), убирая всю эту громоздкую объектную инфраструктуру. Говорю же — я пробовал и так, и эдак.

Опять же -- сидел с секундомером и замерял? И что значит "и так, и эдак"? Оптимизация индексов и запросов при сохранении архитектуры не помогла?

ДГ>Ты сам согласился, что инкапсулировать сложные параметризованные запросы в методы с двадцатью параметрами неудобно. А если вгонять выборку нескольких объектов в один SQL-запрос, подобные ситуации будут возникать на каждом шагу — пусть не с двадцатью параметрами, а с двумя, но всё равно искать концы неудобно.

И какая связь с быстродействием? "Неудобно искать концы" в неудобных средах разработки.

Здравствуйте, WolfHound, Вы писали:

WH>Ты про это?
WH>http://tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all&version=5&currencyID=0
Угу.

WH>Так там вего один кластер. Сделаный в 2004ом... причем это самая быстрая система сделаная в 2004ом...
Именно, а знаешь почему? Неэффективно, просто класс задач такой, узким местом являются сами данные, которые на несколько машин эффективно не растянешь. За последние лет 10, ни одни кластер там долго на первом месте не держался, если вообще до первого дотягивал. Практика показывает, что для таких задач всегда можно собрать одну машину, которая будет дешевле и эффективнее кластера.

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

Здравствуйте, Нахлобуч, Вы писали:

ДГ>>Уверенность оттуда, что я проводил замеры в процессе рефакторинга. Собственно, я и занимался оптимизацией запросов (для скорости) — а заодно упрощал код (для удобства), убирая всю эту громоздкую объектную инфраструктуру. Говорю же — я пробовал и так, и эдак.

Н>Опять же -- сидел с секундомером и замерял?

Скидывал в журнал ($endtime — $starttime).

Н>И что значит "и так, и эдак"?

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

Н>Оптимизация индексов и запросов при сохранении архитектуры не помогла?

Оптимизация запросов помогала — для скорости. И упрощение архитектуры помогало — для простоты. Я же писал. Что ты прицепился к этой архитектуре, как к священной корове?

Н>"Неудобно искать концы" в неудобных средах разработки.

То есть, ты предлагаешь забить на PHP? С удовольствием, но это уже другой разговор.

Здравствуйте, Нахлобуч, Вы писали:

Н>Ну тады звиняйте. "Языками не владею, ваше величество!" ©

Ну и слава Богу! Значит, я ещё и в Сочи да Анапу как-нибудь сгоняю на катере на подводных крыльях. Хотя уродский он... а я так надеялся, что пустили пресноводные красавцы-"Метеоры"...

На самом деле, разговор ни о чём. Человек попросил совет по архитектуре на php5

Автор: SpLove
Дата: 26.06.07

. Я рассказал, как я делаю — дешево и сердито. Ты мне начал доказывать, что на других языках по-другому круче. Но вопрошавшего другие языки не интересовали. Так что мы хорошо поругались ни о чём, и ничего нового не узнали. Поэтому предлагаю эту тему закрыть.

Здравствуйте, IB, Вы писали:

IB>Кластеры бывают разные, повышение надежности и провышение производительности задачи чуть ли не противоположные, и кластеры, соответственно тоже по разному устроены (хотя можно и комбинировать). Кластер, который собрали для повышения отказоустойчивости, по сути большая машина с онлайн бакапом и хот стэндбаем, нагрузка по обработке запроса там не параллелится.
Те ты лучше меня знаешь как у меня кластер работает?

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Так что мы хорошо поругались ни о чём, и ничего нового не узнали. Поэтому предлагаю эту тему закрыть.



Только твое предложение меня заинтересовало. А что если и правда устроить состязание языков-фреймворков-платформ? Не не деньги (не люблю я этого), а исключительно их спортивного интереса -- посмотреть, что в итоге получится. Уже и кандидат есть -- Beast. А? Может, еше кто подтянется.

Здравствуйте, Нахлобуч, Вы писали:

Н>Только твое предложение меня заинтересовало. А что если и правда устроить состязание языков-фреймворков-платформ? Не не деньги (не люблю я этого), а исключительно их спортивного интереса -- посмотреть, что в итоге получится. Уже и кандидат есть -- Beast. А? Может, еше кто подтянется.

Гы, очередной холивар задумал?!

(ворчит) Больше мне заняться нечем... Да и какой смысл устраивать состязание PHP и ASP? Я почти уверен, что PHP отсосёт по всем параметрам. Ни для кого не секрет, что у PHP единственное преимущество — низкий порог вхождения. Убогий язык для убогих задач, не случайно он так распространён на shared-хостинге. А сравнивать ASP и Java я ещё не готов — слишком мало опыта. Разве что через годик-другой (надеюсь) я достаточно освоюсь в J2EE и имеющихся к ней фреймворках.

Здравствуйте, Дм.Григорьев, Вы писали:

ДГ>Гы, очередной холивар задумал?!

Отнюдь. Просто наглядно показать, такскть, Best Practices и методы работы с технологиями -- чтоб разные фреймворки, библиотеки и пр.

Ну да на нет и суда нет.

Здравствуйте, WolfHound, Вы писали:

WH>Те ты лучше меня знаешь как у меня кластер работает?
Причем тут ты?

Здравствуйте, IB, Вы писали:

WH>>Те ты лучше меня знаешь как у меня кластер работает?
IB>Причем тут ты?
При том что у меня запросы паралелится и отказоустойчивость обеспечивается.

Здравствуйте, WolfHound, Вы писали:

WH>При том что у меня запросы паралелится и отказоустойчивость обеспечивается.
И как это влияет на то, что задачи отказоустойчивости и производительности разные, и что для отказоустойчивости необязательно становиться полноценным кластером с распараллеливанием нагрузки?
Я, собственно, утверждал, что для OLTP поставить два больших сервера с хот-стэндбаем и не параллелить запросы, будет намного эффективнее (при сравнимой, если не при большей надежности), чем разворачивать кластер из машинок поменьше, умеющий распараллеливать нагрузку, и плюс к этому, обеспечивать отказоустойчивость.

Позвольте узнать, с чем не согласны.