Про 6 лет назад и выбор - согласен 100%. Из причин - есть еще такое понятие как "мода".
Ну да, я и написал - набор текстовых файлов. Имел в виду директорию с файлами.
Там только одна засада. На Юниксе мы как то уперлись в количество файлов в папке. Забыл предел, но в общем когда их стало ОЧЕНЬ МНОГО машина померла наглухо. Даже процесс удаления было запустить уже очень сложно. Не знаю, может щас все уже усовершенствовали конечно.
Про OS в которых файловая система на СУБД - это Vista что ли ;)? Вроде б анонсировалось так, да вроде б не доделали... Или я что-то путаю - еще туда не лазил.
А все таки про универсальным механизм... Для веба мне верится что можно (хотя, возможно что специализированное решение будет более производительным). И пофигу как страница собирается, в смысле из каких данных. Можно сделать свой над-слой из HTML-блоков, которые уже дальше там в кэшировании и участвуют. А как они там собираются, из каких таблиц - все равно. В принципе у нас так сейчас и работает, правда пара идей еще продумывается. Пределов совершенству нет :).
Полигон на javascript произвольной формы не нарисуете, его придется сгенерировать на серверной стороне (PNGшку скорее всего). Движение вместе с картой делается средствами Google Maps API, тут даже ничего писать не придется, практически.
Для курсовой задачка слабовата, честно говоря. Примерное время решения (чтобы было все красиво) на мой взгляд 2-4 часа максимум. С учетом изучения доки на Google Maps API.
Вообще, можете почитать у Лебедева в техногрете описание админского интерфейса к бизнес-линчу. Может на какие мысли наведет.
Пишете глупость.
Что значит "не нужно" - вообще не понял. Я имел в виду ОО стиль написания кода. Можно написать на Перле скрипт так, что вы с первого взгляда не поймете (мелочи в синтаксисе не в счет) на чем написано. И как следствие - трудоемкость разработки одного и того-же для большинства несложных задач будет совершенно одинакова.
А про "прост" я как раз выше и написал. Для опытного программиста на самом деле вообще пофигу на каком языке писать. И Перл нисколько не сложнее PHP. Это заблуждение.
Насчет "PHP удобен" - это вы расскажите любому, кто работал с большими и сложными регекспами. Поэтому ваше утверждение безотносительно ситуации не имеет права на жизнь.
Каждой задаче - свое решение. Любая попытка сравнивать эти языки - незнание матчасти. Но поскольку тут в основном веб-разработчики дискутируют - каждый выбирает язык для себя сам.
Лично мне Perl симпатичен больше, но только потому что так случилось исторически, что с ним я познакомился раньше. И в итоге знаю его на порядок лучше. Да, начинал я смотреть тогда же и PHP, но тогда он был еще в пеленках и не было бумажной литературы а с интернетом было хреново чтобы в доки онлайн лазить по каждому вопросу. Хотя, несколькими годами позднее все могло бы сложиться иначе. Но я нисколько не жалею.
На Perl полно CMS. А насчет энтузиастов - покажите пальцем хоть один российский продукт приличного уровня, созданный командой энтузиастов числом более одного. По сравнению с open-source индустрией "там", у нас глухо как в танке.
Само собой для разработчика есть логи ошибок. И такая вещь как use CGI::Carp qw( fatalsToBrowser ). Поэтому, если не замечать смайлика, то это препятствие только для ламеров.
А с практической точки зрения - слава богу, что детальная информация об ошибке в CGI врагу недоступна. Незачем ему знать что там случилось.
Вопрос ТС видимо проистекает из абстрактного любопытства (?) и/или незнания истории создания этих двух языков. Сравнивать их некорректно, поскольку создавались они для совершенно разных целей и в разное время. Соответственно, они по-разному устроены идеологически и с разной эффективностью решают одни и те же задачи. Веб для Перла строго говоря не целевое применение. Поэтому на порядок меньше книг по его использованию в CGI программировании. Поэтому обучение Перлу строится совсем не на тех примерах, чтобы любой студент мог его взять за основу для веб-разработок.
А в результате его синтаксис, отсутствие объектной модели и малое количество примеров заточенных под веб становятся труднопреодолимыми препятствиеми для начинающих. С этой точки зрения PHP - путь наименьшего сопротивления.
Подтверждением является распространенное мнение, что
В данном случае простота языка сама по себе - абстрактное понятие. На перле можно программировать "в стиле PHP". Равно как очень много PHP программ написано в жуткой форме, намного более ужасной чем пишет (писал) начинающий на GW-Basic 3.18. Но PHP заточен под веб. А перл - нет.
Какая разница какая база-то? XML хранилище это тоже база. И набор текстовых файлов - тоже база. И plain text database - тоже база. Любое хранилище данных можно характеризовать временем выборки данных. Для набора текстовых файлов оно практически не будет зависеть от объема данных до определенного порогового значения, которое определяется файловой системой. Для реляционной СУБД как правило это логарифмическая зависимость. Для XML файла без дополнительных ухищрений это практически линейная зависимость.
Поэтому все что вам "говорят" разработчики можно легко протестировать применив здравый смысл и зная алгоритмы обработки данных. Со времен выхода книг Д.Е.Кнута мало что изменилось так чтобы кардинально.
Не совсем понял что имеется в виду под индексной страницей, но проблема решается в рамках логики работы кэша, который учитывает изменение контента. То есть я имею в виду что сам по себе контент не протухает никогда. А то, что страница зависит от изменения сразу многих блоков - это естественно. И сделать нормальное правильное обновление всех страниц, которые зависят от изменненного блока - это задача алгоритма.
Это тоже неправильно :). Выборка из БД (при использовании индексов, то есть если все сделано не через одно место) по времени никак не зависит от размера БД. Ну, почти, то логарифмическая там зависимость. Также производительность сервера при работе статического кэша будет очень мало зависеть от HDD. Более менее серверные компоненты по степени влияния нужно расставить так (IMHO):
Сильное влияние в зависимости от ситуации могут оказывать:
- пропускная способность интернет-канала на сервере
- пропускная способность шины материнки
- объем памяти
- качество сборки сервера, наличие конфликтов по железу, в т.ч. и удачная совместимость и способность компонентов не мешать друг другу и максимально использовать свои возможности
- охлаждение и блок питания (где-то тут, но не уверен что тут, но уверен что влияние большое и это важно)
- количество процессоров
Среднее влияние, сильно зависит от архитектуры решения:
- винты - скорость чтения
Малое влияние если все корректно спроектировано:
- герцовка процессора
- винты, скорость записи
Что-то в этом духе.
Вероятно в таком вот аксепте неправильно понял. Но еще раз - если механизм кэширования доведет контент до статики - какая разница сколько уникального контента? Посещаемость же ТС не упоминалась вовсе. А увязывать посещаемость с количеством контента я честно говоря не стал бы, хотя может быть какая-то корелляция и будет если рассчитывать на случайный трафик.
Мэкс, Вы имеете в виду "многие ко многим" в исходной структуре? То есть что первичная генерация страницы в кэше будет долгой и пока кэш не построиться время "усредненное время ответа" будет то большим, то маленьким (если в кэше уже лежит страница), так? Мне кажется, что это не есть большая проблема, если учитывать тот факт, что "время протухания" для кэша "вообще" шутка бессмысленная. Зачем контенту "протухать"? Право на жизнь имеет только сброс страницы по изменению контента, причем генерация может быть осуществлена тем, кто меняет контент, а не посетителем. Вот это на мой взгляд правильный подход и в принципе не сильно сложный то в реализации. Тем более для простого статейного сайта, где по идее на странице со статьей не так много контенту то еще какого динамического должно быть.
Единственная проблема - первоначальное наполнение кэша, но опять же это наверное для 90% ситуаций не так страшно, если генерация страниц немного потормозит. По идее безотносительно задачи генератор страницы всегда должен быть специализирован под структуру хранения данных, а механизм кэширования почти всегда от нее наоборот не зависит. Хотя, это конечно каждый реализует как хочет.
Про статическое кэширование не понял - почему именно 3-4 раза в день? Интересен путь получения вывода. Сам прикинул, но связи между количеством контента и частотой обновления статического кэша не нашел. Равно как и необходимости его обновлять вообще (если только конструктор кэша вообще не знает ничего об изменениях в данных, это имелось в виду?).
