RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : MySQL или JSP?


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Pilot
To : Eugen Kuleshov
Subj : MySQL или JSP?
> > В принципе, на перле это делается так же. Обработку данных делают одни функции, представление результатов - другие. Причем и то, и другое - максимально гибкое, поскольку даже HTML относящийся к "оформлению" генерируется динамически и можно использовать разные красивые и удобные трюки. Хотя это не всем нужно конечно. Но тогда можно и PHP обойтись.
>
> Брр. perl и php весьма близки по возможностям.

Не смеши меня. Это все равно как если бы я сказал что Java и PHP близки по возможностям :). Перл - полномасштабный язык программирования и среда разработки, на нем можно писать _абсолютно_ любые программы: развитый стандартный API, доступ ко всем нативным API, горы библиотек с расширениями.

> Java же, в отличие от этих скриптовых языков предоставляет реальные средства для объектно-ориентированного дизайна и разработки приложений. Такие, как например сокрытие информации, наследование и полиморфизм.

Это все есть в Perl. Perl5 - объектно-ориентированый язык програмирования, весьма развитой. Может ты про перл последний раз слышал лет пять назад - тогда да, это было нечто вроде улучшеной версии awk. Но те времена - уже доисторические.

> > Неэффективно в чем? Главная проблема
> Тем, что приложение запускается и прибивается на каждый запрос пользователя.

На то есть FastCGI и иже с ним (mod_perl). А если http сервер грамотно написан так он вообще это делает совершенно прозрачным образом. Еще раз повторяю - попробуй PW, увидишь что такое _эффективный_ сервер. Апач рядом не валялся, даже с mod_perl.

> Первая проблема которая возникает - куда положить данные, которые хотелось бы сохранить в промежутке между запросами.

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

>Кроме того есть некоторые весьма удобные вещи, как, например утилизация конектов к базе данных в запросах. В CGI ты будешь вынужден конектиться каждый раз. Что не есть хорошо для производительности, а на корпоративных системах, ворочающих большими объемами можно натолкнуться еще и на предел одновременных конектов, устанавливаемый SQL сервером (не зря же изобретали 3х уровневую архитектуру).

Это тоже обходится соотв. расширениями сервера. Опять же, грамотный сервер делает это прозрачно, вообще ничего програмировать не надо. Написаный левой ногой Netscape Enterprise Server с которым мне приходится иметь дело - требует подкручивания и поглаживания, но однако тоже это умеет. Кроме того, для этого есть средства и в DBI.

> Нет, мне это нарвится. "часть модулей тоже бинарные". Да хоть одна функция будет бинарной и не дай бог не соберется (в Java то bytecode и собирать никуда не надо), то скажи перлу до свидания. :)

При чем тут bytecode? У перла тоже байткод, ну и что? Речь идет о самом интерпретаторе, или о JVM. Оно естественно должно быть перенесено на систему в бинарном виде. Модули расширения являются частью интепретатора Perl, так что естественно они должны быть собираемы на этой системе. JDBC тоже кстати бинарные по большей части, и это тоже проблема, как я уже писал.

> А JDBC для Oracle еще никто не отменял. :)

Есть только для WinNT. И экспериментальный lightweight на pure Java. Подозреваю что оно нерабочее. Я же писал уже, ты что текст ответов не читаешь?

> JDBC

Нету ни для чего кроме WinNT. DBI есть для всего.

> Я про байткод. Ты не отдаешь исходные тексты. Ничего не надо собирать. А байткод работает везде, где есть JVM, удовлетворяющая спецификации.

Это да, проблема. Исходники отдавать не хочется. Но вообще-то уже есть компилятор perl в байткод и он уже даже работает. Правда пока это все же бета.

> Ну знаешь. regexp'ы ему нужны... Взял да написал сам. Один раз. И всем другим дал,

:-))))))))))

чтобы не мучались. Хотя лично я не верю, что нет нормальных regexp'ов. Ту же Cшную либу,

Ну и не верь на здоровье. Я-то проверял...

> которой все пользуются (perl в том числе) вполне можно перетащить на Java. Будет один в один, если не лучше даже. :)
>
> > Стану, да еще как! Мои коллеги попробовали поставить JVM на свой сервер под CGI, Октан у них там какой-то или еще круче, не помню. Он упал так что они его потом месяц восстанавливали.
>
> Уууу... CGI - это абстракция. Это абсолютно ничего конкретного. То есть совсем. Это даже не программа. :)

Я описАлся. Имелось в виду SGI, Silicon Graphics Inc., это железяки такие, синенькие... Хардверная платформа в общем.

> Ну еще бы они его не слышали. Этому слову лет 7..8 пожалуй будет. Java - всего 5. А JDBC и того меньше. А учится админам никогда не вредно. Или хотябы научно-популятные журналы читать. :)

И где ты видел сисадмина читающего научно-популярные журналы? :-))) Они все - с красными глазами и мозолью на заднице :))))

> Слышал я как Нечаев три дня бился головой об стену в попытках собрать mod_perl для осевого Apache. Нафиг, нафиг нам такая

У меня база с которой я работаю не под осью.

> радость. А ты не смотрел в каком месте твой PersistentCGI хранит результаты меду запросами? Так вот посмотри, порадуйся.

Рассказал бы, я им как раз не пользуюсь.

> FastCGI у меня только нервный смех вызывает. Что, еще есть SlowCGI? :)
> А как насчет load balancing? N серверов приложений или, скажем K SQL серверов для одного...M httpd.

Не понял, поподробнее можно? Видимо передо мной такой задачи еще не вставало, а разбираться во всех мыслимых проблемах мироздания я не успеваю :-).

> Ты видимо мельком и смотрел раз такие вещи говоришь. Вон Дима Платонов не даст соврать. Или хотябы сходи на сайт java.sun.com и в разделе документации про JDBC там отдельная страница есть, посвященая списку JDBC драйверов для немерянного кол-ва серверов.

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

Mon 03 Dec 2001 18:39 Mozilla/4.61 [en] (OS/2; I)



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.