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


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

Java - тоже технология между прочим. Стандартом ее обозвать можно с большой натяжкой. Это и язык и идеология.

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

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

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

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

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

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

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

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

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

JDBC

> > случае с Java мы имеем _бинарную_ совместимость. Причем и для OS/2, и для win32, и для Sun, и для...
>
> Не понял, какая еще бинарная совместимость у джавы? Джава - интерпретируемый язык. Или ты про JVM? Но интерпретаторы Perl (бинарные естественно) есть на большем числе платформ чем JVM.

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

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

Ну знаешь. regexp'ы ему нужны... Взял да написал сам. Один раз. И всем другим дал, чтобы не мучались. Хотя лично я не верю, что нет нормальных regexp'ов. Ту же Cшную либу, которой все пользуются (perl в том числе) вполне можно перетащить на Java. Будет один в один, если не лучше даже. :)

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

Уууу... CGI - это абстракция. Это абсолютно ничего конкретного. То есть совсем. Это даже не программа. :)

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

Сильно частный случай. Ты вот не сможешь же 2х часовой фильм в 3Dмаксе нарисовать сев за него первый раз в жизни и потыркавшись по менюшкам минут пять. Тут тот же случай.

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

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

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

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

> > > и отсутствие нативных клиентов под OS/2 для большинства последних версий БД. DB2 и MySQL - исключения, а вот для Oracle 8 Perl DBD драйвер под осью уже не соберешь.
> > В Java это не является проблемой.
> Это как посмотреть. Пока не увижу работающего Oracle Pure Java JDBC - не поверю. Что-то у них там больно много слов lightweight и experimental в его описании мелькает. По-настоящему нативный JDBC - только для WinNT. Вот тебе бабушка и run everywhere :(.

Ты видимо мельком и смотрел раз такие вещи говоришь. Вон Дима Платонов не даст соврать. Или хотябы сходи на сайт 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.