мне читать про оптимизацию?   ты советуешь мне читать про оптимизацию?

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

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

 Судя по всему тебе всенепременно стоит прочитать эту статью. Там на эти твои вопросы ответили.

Посмотрел на DbSimple, тоже старый велосипедный подход используется, тот же raw-SQL, не советую пользоваться подобными поделками. Лучше обрати внимание на лучшие решения.


Это сообщение отредактировал(а) source777 - 31.5.2009, 18:25

source777, что это за набор паттернов? 

Тот класс для работы с БД, что ты показывал до этого как я понял не использует SQL, за место него работает объектная модель? Я думаю, что это неправильно, так как не зря же придумали SQL? Могли бы и сразу делать объектно, без всяких других языков.

да что за статья-то?

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

 Я хочу сказать, что разницы нет.
И кстати не забывай, что php-файл после компиляции кэшируется при правильной настройке PHP ;)

PoEAA.

Проще говоря, ты не используешь ООП, а ставишь БД во главу угла. Если ты пишешь только сайты-визитки, то пожалуйста, а в крупных веб-приложениях такой подход просто недопустим. Кстати SQL этот подход использует, только он его изолирует в одном месте - ActiveRecordBase и его потомки.


Тут ты не прав, SQL зародился очень давно(ещё в 70-х годах), в то время его не могли сделать объектно, а сейчас мгновенный отказ от реляционных СУБД уже просто невозможен, но идёт плавный переход от них в сторону объектно-реляционных и объектно-ориентированных СУБД. И самое забавное, что сами создатели реляционной модели данных утверждают, что SQL не является истинно реляционным языком(и забросив его принялись за Tutorial D). 
Но даже при использовании реляционных СУБД уже давно всем понятно, что SQL никак не вяжется с современным объектно-ориентированным программированием, поэтому все запросы должны быть изолированы в одном месте, а не разбросаны хаотичными вкраплениями по всему коду.

Это сообщение отредактировал(а) source777 - 31.5.2009, 19:36

source777, а есть ещё альтернативы ActiveRecordBase? 

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

Есть, по ссылке выше смотри пункт Data Source Architectural Patterns.

Хороший код должен быть:
1) Хорошо читаемым
2) Хорошо документированным
3) Хорошо оптимизированным

Имхо. требования к написанию меняются от команды к команде... 

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

Это сообщение отредактировал(а) youri - 31.5.2009, 22:51

так я ж про то и говорю, сто файлов подключаются одновременно. это же с ума сойти

Кстати, рекламируемая тут ActiveRecordBase как раз подразумевает создание большого кол-ва файлов. По файлу на класс объекта.

Это не с ума сойти, а хороший API интерфейс, наверное... В данном случае кеширование спасет мир. Например, установи pear'овскую ACP. Иногда скорость выполнения повышалась до 83%