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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Pilot
To : Eugen Kuleshov
Subj : MySQL или JSP?
> > [skipped] А JSP это стандарт доступа к таким базам (разным) с использованием JDBC и Java servlets.
>
> JSP это совсем не стандарт доступа к базам данных. Это технология, позволяющая

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

генерировать динамические документы на лету. Язык написания Java. После компиляции JSP-страницы получается Java servlet, который и запускается на выполнение. При этом можно использовать все множество API, доступное для Java. Удобство технологии JSP в сравнении с Java servlets в том, что не требуется перекомпиляция при изменении HTML кода (дизайна) страницы. Часто используется связка servlet (для работы с данными) + JSP (для презентации этих данных).

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

> > Я могу посоветовать в качестве инструмента доступа к базе Perl5 с модулями DBI/DBD и CGI (последний - если доступ из броузера, с формами, менюшками и пр.).
>
> CGI - слишком уж неэффективно.

Неэффективно в чем? Главная проблема сейчас - разработка программ, а не их исполнение. Это раньше можно было нанять 100 програмистов чтобы они обслуживали один компьютер, а сейчас если на 100 компьютеров есть один програмист - уже хорошо. Так что главное - эффективность разработки, а здесь перл на высоте. Все-таки интерпретируемые языки имеют свои преимущества. Впрочем, Sun это тоже понимает...

> > Сейчас меня тут закидают тухлыми яйцами поклонники Java, но перл имеет несколько преимуществ: 1) перл он и в Африке перл, по *реальной* переносимости кода даже Java ему пока не конкурент (подчеркиваю - пока, что бы там ни писали в рекламных пресс-релизах),
>
> Уууу... я фигею дорогая редакция. Если есть бинарные модули для конкретной платформы для доступа к SQL RDBMS или еще к чему, то ком может и будет переносим, но вот ещели таковых модулей нет, то облом. В

Какие бинарные модули, какой ком? Речь идет о перле. Программа на перле работает сразу на любой платформе на которой установлен интерпретатор перла. Естественно, сам интерпретатор бинарный, и часть модулей расширений к нему тоже бинарные, но это уже проблемы сборки перла на конкретной платформе. Естественно, если пользоваться комерческими SQL серверами, то в части их поддержки - ты полностью в руках фирмы-разработчика. Это касается и перла. Ну не хочет Оракл больше поддерживать OS/2 и все, облом. Исходников-то нету.

Но в принципе текущая реализация SQL API в перл очень неплохо задумана и сделана: есть два уровня, первый - собственно API для разработчиков, он обеспечивается модулем DBI (Database Interface) и он полностью независим от конкретной реализации DBMS. Второй уровень - модуль DBD (Database Driver), он "заворачивает" функции API DBI в
SQL engine-specific функции, прозрачным для пользователя образом. При этом если очень нужна какая-то специфическая нестандарнтная функция конкретного сервер - ее можно вызвать обратившись напрямую к DBD, пожертвовав при этом переносимостью естественно. А если этого нет - то смена одной RDBMS на другую производится заменой названия драйвера DBD, а сама программа продолжает работать как ни в чем не бывало.

случае с Java мы имеем _бинарную_ совместимость. Причем и для OS/2, и для win32, и для Sun, и для...

Не понял, какая еще бинарная совместимость у джавы? Джава - интерпретируемый язык. Или ты про JVM? Но интерпретаторы Perl (бинарные естественно) есть на большем числе платформ чем JVM.

> > 2) на перле написано огромное количество готовых модулей для любых более-менее стандартных операций, в том числе для доступа к БД, самому програмировать придется минимум,
>
> та же фигня с Java.

Та же, да не та :). Конечно, в джаве я меньше понимаю чем в перле, но вот конкрентная проблема - мне для работы с базой нужны regexp, а где они в джаве? Есть конечно пара попыток написать нужные классы, но все это детсадовская самодеятельность, для промышленного использования не подходит, а уж про надежность лучше и не вспоминать. Впрочем, это вообще слабое место джавы. А без regexp мне не жизнь, так что для моего конкреного проекта джава как платформа пока отпала. Я повторю - пока. Я верю что джава - более прогрессивное решение чем перл, но это все еще игрушка. Впрочем, перл тоже был игрушкой не так давно.

> > 3) отнюдь не всегда можно добиться того чтобы на системе под которой стоит БД к которой надо делать доступ была установлена поддержка Java, JDBC, JSP и пр. Перл как правило стоит везде, а если нет - так устанавливается легко, даже на WinNT.
>
> Не станешь же ты утверждать, что JVM установить сложнее чем perl. А все, что ты

Стану, да еще как! Мои коллеги попробовали поставить JVM на свой сервер под CGI, Октан у них там какой-то или еще круче, не помню. Он упал так что они его потом месяц восстанавливали. Теперь слово джава они слышать не могут. Это кстати была вторая причина по которой джава отпала в качестве платформы для моего текущего проекта. Может конечно у их сисадмина руки были кривые, не знаю, но перл вместе с DBI/DBD он поставил за два дня. Так долго - потому что это крупная фирма и у них секурити на всю катушку - чтобы поставить любой новый софт на сервере надо запрашивать разрешения по инстанциям и тп...

>перечислил - JDBC, JSP и т.п. - это вещи написанные на Java и единственное что нужно сделать - это положить библиотеки рядком с JVM.

Для начала - надо чтобы сисадмин на том сервере где установлена база данных разобрался в принципиально новой для него технологии. Чтобы он хотя бы _захотел_ разобраться... Это не так просто. Хорошо если сервер в соседнем здании, пошел, все показал, носом сунул... А если - в другой стране? И в другой фирме, у которой свои понятия о том что хорошо и что плохо? Перл-то у всех стоит, и слово CGI все сисадмины слышали...

> > Минусы - низкая производительность (а оно надо для интерактивного приложения которое в основном ждет пока тупой пользователь нащупает какие кнопочки ему нажать?)
>
> После некоторого кол-ва пользователей, использующих софтину одновременно это уже становится проблемой. В JVM при хорошем проектировании можно получить быстродействие весьма близкое к коду, написанному на C/C++ (не забывайте о JIT!).

На это есть FastCGI, PersistentCGI и perl_mod. А аналог JIT был в перле сроду. Эх, ты бы видел как PowerWeb с перлом работает, как масштабируется, просто песня! Сволочи компусорсовцы, такой сервер убили. Давить гадов...

> > и отсутствие нативных клиентов под OS/2 для большинства последних версий БД. DB2 и MySQL - исключения, а вот для Oracle 8 Perl DBD драйвер под осью уже не соберешь.
>
> В Java это не является проблемой.

Это как посмотреть. Пока не увижу работающего Oracle Pure Java JDBC - не поверю. Что-то у них там больно много слов lightweight и experimental в его описании мелькает. По-настоящему нативный JDBC - только для WinNT. Вот тебе бабушка и run everywhere :(.

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.