-> edogs
Не принимается.
Достаточно использовать индексы в таблицах. Ознакомьтесь пожалуйста с этим полезным свойством таблиц.
при серьезной посещаемости сайта и большой нагрузке на сервер такие запросы все равно съедают лишние ресурсы...
использование индексов - абсолютно очевидно, я рад что вы открыли для себя такое "полезное свойство таблиц"... я так понимаю, недавно?
Не принимается.
а) Выборка из каталога файла не факт что будет быстрее чем выборка из таблицы данных, даже если учесть время передачи. Классичный пример - 5000 файлов в каталоге и 5000 записей в базе.
для выборки из базы необходимо:
1) PHP должен открыть соединение с базой
2) БД должна открыть файл хранящий данные (я имею в виду файл в котором хранятся таблица(ы) базы данных)
3) найти и прочитать нужную информацию в этом файле... причем БД будет выполнять кучу действий связанных с чтением индекса, потом поиском по индексу, и затем поиском по таблице-файлу...
4) после этого нужно будет еще передать данные в PHP парсер через открытое соединение
Если же страница лежит просто на диске в виде файла, то веб-серверу достаточно выполнить только чтение файла с диска и отдать этот файл PHP парсеру. Это намного быстрее, чем работа с базой.
б) Есть форум vbulletin. Мы работали над его оптимизацией по скорости на одном сайте. В форуме можно выбирать где хранить файлы (картинки, обычные файлы), в базе или в файловой системе. После того как мы сменили способ хранения на базу, скорость заметно (в 2 раза) улучшилась. Подумайте над этим.
если скорость увеличилась настолько серьезно... в 2 раза... то боюсь причиной увеличения производительности скорее всего стала смена алгоритма работы форума, связанного с изменением этих настроек... тут дело совершенно не в том где именно хранится файл, а в том как с ним работают.
Не принимается.
Для статического хтмл сайта надо использовать цмс генерящие статические хтмл страницы, а для динамического этот принцип реализуется с помощью несложного кэширования.
заранее сгенерированные HTML страницы как и полностью закэшированные страницы накладывают _серьезнейшие_ ограничения на возможности системы... (если по этому пункту возникают вопросы - прошу)
Не принимается. Ибо не факт.
Аргументировать против не будем, так как сама изложенная точка зрения на этот пункт весьма однобока.
простота в программируемости страницы - одно из важнейших(!) преимуществ принципа 3.
боюсь как раз в этом и состоит главное(!) преимущество принципа 3.
жаль что у вас не находится аргументов.
принцип 3 - позволяет изменять структуру сайта просто перемещая файлы,
Так же как и первые два.
принцип 1, 2 не позволяет управлять структурой сайта манипулируя _только_ файлами на диске... оба этих способа предполагают также и изменения в БД...
боюсь вы меня не поняли.
К сожалению ни одного недостатка Вы не привели. А вот преимущества очевидны.
недостатки я привел - тот кто захочет понять - поймет.
Достаточно очевидно что лес на структуре дерева не построить.
вы упомянули об ограничениях, я попросил вас привести пример проявления подобных ограничений.
Судя по Вашим аргументам это именно игра воображения, при чем нехилая такая игра. Каждое Ваше "возражение" мы опровергли. При том каждое Ваше возражение показывало или незнакомство с вопросом или намерянное игнорирование фактов.
edogs, очевидно что вы просто не встречались и не работали с CMS основанных на принципе 3... а в силу природной упрямости и обидчивости просто не способны рассуждать трезво и понять всех преимуществ этого подхода.
фактов у меня как раз более чем достаточно так как приходилось разрабатывать CMS основанные на всех 3 принципах.
Поэтому продолжать разговор смысла не видим.
потом пойдут "до свидания"?
банально.
с удовольствием воздержусь от бесполезного общения с вами.
