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

Уменьшение потребления памяти модулем modjperi

Существуют методы, позволяющие активизировать для модуля mod perl только определенные процессы сервера Apache Таким образом расход памяти увеличивается только для тех процессов, которые выполняют сценарии Perl. На Web-узле Apache есть раздел, полностью посвященный дискуссии о различных возможных стратегиях (см. http: perl.apache.org/guide).

Подводя итог всему сказанному, можно резюмировать, что независимо от выбранного языка, нужно стремиться к тому, чтобы использовать модульный режим работы интерпретатора, а не автономный. На откуп автономной форме работы интерпретаторов можно оставить те задачи, которые невозможно обработать в модульном режиме, как это было в случае, когда запускаемому сценарию необходимо присвоить определенные привилегии. В таких случаях сценарий можно обработать с помощью механизма suEXEC Web-сервера Apache. Он запускает интерпретатор под указанным идентификатором пользователя.

Время разработки программ

Все описанные выше факторы влияют на производительность приложений. Но просто эффективность выполнения программ не может являться единственной целью. Время разработчика тоже является существенным фактором, поэтому простота профаммирования тоже должна приниматься во внимание. Создание приложения на языке Perl может занять вдвое меньше времени, чем создание аналогичного приложения на языке С. Поэтому предпочтение может быть отдано Perl DBI API, а не С API, даже принимая во внимание тот факт, что приложение не будет работать достаточно бысфо. Для профамм, которые будут запускаться не так часто, предпочтение обычно отдается тому инсфументарию, который позволяет разрабатывать приложение в короткие сроки. Час времени разработчика сейчас стоит значительно дороже часа машинного времени!

В общем случае, языки написания сценариев позволяют написать действующую профамму быстрее. Особенно это ценно для написания макетов будущих приложений. Здесь ифает свою роль по крайней мере два фактора.

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

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

Во-вторых, цикл разработки программ с помощью языков написания сценариев можно разделить на несколько этапов. Язык С предполагает обычный цикл редактирование-компиляция-тестирование . После каждого внесенного изменения в программу, программа перекомпилируется и только после этого тестируется. Разработка программного обеспечения с помощью языков Perl и РНР предполагает упрощенный цикл редактирование-тестирование , потому что запуск сценария возможен сразу же после редактирования безо всякого компилирования. Однако компилятор накладывает больше офаничений на профаммы в виде сфогой проверки типов. Дисциплинирующее влияние компилятора позволяет избегать фивиальных ошибок, которых бывает трудно избежать в языках Perl и РНР. Компилятор С обязательно предупредит разработчика о наличии ошибки в имени переменной. Язык РНР такого предупреждения не сделает, а язык Perl сделает, только если разработчик об этом попросит. По мере увеличения объема разрабатываемой профаммы будет возрастать и вес этих офаничений.

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

Есть возможность совместить эти два подхода. Сначала профамму можно написать в форме сценария как черновой вариант . С его помощью можно проверить правильность работы алгоритма. Если профамма доказала свою жизнеспособность и частота ее выполнения высока настолько, что на первый план выходит фактор производительности, профамму можно переписать с помощью компилирующего языка профаммирования. Это позволит воспользоваться преимуществами обоих методов: бысфое получение макета и отличная производительность конечного профаммного продукта.

В сфогом смысле, интерфейсы Perl DBI и РНР API не предлагают таких новых возможностей, которых бы не было в клиентской библиотеке языка С. Это происходит потому, что оба интерфейса осуществляют Доступ к СУБД MySQL через подключение библиотеки MySQL С к интерпретаторам. Однако среды, в которых реализуются возможности СУБД MySQL для языка С и языков Perl и РНР, существенно различны.

Рассмотрим некоторые ситуации, которые могут возникнуть при взаимодействии с сервером MySQL, и спросим себя, каким образом язык интерфейса может помочь вам в этом. Вот некоторые примеры.

Управление памятью. В языке С задачи динамического распределения памяти осуществляются функциями malloc () и free (). Языки Perl и РНР делают это с помощью своих внутренних механизмов. Например, в случае автоматического роста размера массива или строк динамической длины разработчику не придется заботиться об управлении памятью.

ш Манипулирование строками. Язык Perl имеет самые развитые возможности в этой области, язык РНР идет вторым в этом списке. (Для сравнения: язык С в этом отношении сильно отстает.)

Конечно, для упрощения своих задач на языке С можно написать свои библиотеки, которые бы рещали такие задачи, как управление памятью и обработка текста. Но их надо будет отладить и позаботиться, чтобы они работали эффективно. В то же время, аналогичные алгоритмы языков Perl и РНР хорощо отлажены и эффективны, так как они были опробованы на практике множество раз. Таким образом разработчик может сэкономить свое время и воспользоваться надежными плодами чужого труда. (Если интерпретатор содержит ощибку, это вполне можно пережить и дождаться, когда она будет устранена. При написании программы на С, разработчику потребуется более тщательный контроль над поведением профаммы )

Рассмафиваемые языки профаммирования различаются уровнем своей безопасности. Интерфейс С API обеспечивает интерфейс с сервером самого низкого уровня и самую слабую защиту. В этом смысле интерфейс С обеспечивает самый низкий уровень защиты. При неверном использовании функций API, в лучщем случае можно получить ощибку out-of-sync ( рассогласование ), в худщем случае - крах программы. Механизмы языков Perl и РНР имеют более высокий уровень защиты. Самое Сфащное, что может произойти при ошибочных действиях, - это сбой сценария, но краха интерпретатора не наступит. Еше одним источником ошибок, чреватых крахом, в языке С можно назвать использование динамического распределения памяти и указателей, связанных с ними. Языки Perl и РНР сами осуществляют управление памятью, и вероятность их краха в результате ошибок, вызванных управлением памятью, значительно меньше.

Время разработки программы на каком-либо языке зависит от объема внешней поддержки, доступной для этого языка. Внешняя поддержка языка С доступна в форме библиотек, содержащих функции интерфейса С API СУБД MySQL в виде подпрофамм, которые проще использовать. Такие библиотеки имеются как для С, так и для С++. Без сомнения, Perl имеет большее число дополнений в виде Perl-модулей (аналогично модульной концепции Web-сервера Apache). Существует специальная ин-фрасфуктура, предназначенная для упрощения поиска этих модулей