Что выбрать (PYTHON PERL PHP)(MySQL, PostgreSQL)?

cherny
Дата: 24.08.2006 21:00:33
Здравствуйте уважаемые!

Требуется разработать приложение с Web-интерфейсом (web-based) работающее с БД. Нужно выбрать язык для реализации веб интерфейса и базу данных. Все это должно быть свободнораспространяемым.

Жду ваших аргументированных высказываний (предлагать можно что-то и не из списка). Замечательно было бы увидеть общие приемущества и недостатки предлагаемых инструментов.

Заранее спасибо
g613
Дата: 24.08.2006 21:37:58
...сильно подозреваю, что все обсуждение уйдет в бональный холивар... а уж при такой постановке вопроса - пишите на том, что лудше знаете, ибо любой продукт из вышеприведенного списка удовлетворяет вашим требованиям...
Anjey aka PM
Дата: 24.08.2006 22:06:53
если интересует именно приложение (WEB Application) тогда вам копать в сторону Java.

Ну а из вышеприведенных платформ я бы выбрал Перл или Питон. ПХП для серьезных проектов неподходит, т.к. не является серьезным продуктом. Хотя для малого и среднего бизнеса более оптимальными могут быть и решения на ПХП.

Насчет СУБД -- тут уж действительно все зависит от задач.

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

Если же вам надо простое, небольшое и шустрое решение то мускул вам подойдет оптимальнее.

ЗЫ: вышенаписанное это всего-лишь мое ИМХО и посему прошу не считать его советом к действию. Опять таки повторюсь: все зависит от конкретной задачи, наявных аппаратных (ну впрочем и материальных) средств, времени на разработку приложения и знания программистами выбранного программного продукта.
pamir
Дата: 24.08.2006 23:00:20
Anjey aka PM

Слон - он действительно слон: большой, тяжеловесный и неповоротливый,

Ну ничего себе. Вот так взял и опустил слоника
Кстати, на счет свободно распространяемого - слон как раз свободный, а мускул свободен пока ты не начинаешь на нем зарабатывать (примерно так, в подробности не вдавался, оставлю это для автора топика).

Все действительно зависит от задач. По мне, (как ораклиста) так слон лучше - он близок к ораклу по идеологии. Вообще не могу себе представить БД без транзакций (в мускуле кажись они появились. Да?)

На счет средств не скажу - нужна конкретика.
*
Дата: 25.08.2006 00:05:40
g613
пишите на том, что лудше знаете
+1
Anjey aka PM
Дата: 25.08.2006 00:28:44
в мускуле действительно есть паскудство с лицензиями

Насчет слоника -- не хотел я его опускать, он мне самому нравится, но для большинства задач я бы его не использовал.
DocAl
Дата: 25.08.2006 01:25:49
pamir

Все действительно зависит от задач. По мне, (как ораклиста) так слон лучше - он близок к ораклу по идеологии. Вообще не могу себе представить БД без транзакций (в мускуле кажись они появились. Да?)

В MySQL они БЫЛИ уже в 3.23 года 2001, за раньше просто не берусь говорить.

Ну вот, вопрос действительно скатывается к холивару...( PHP вот несерьёзным уже назвали, в транзакционности MySQL усомнились...)

Конструктивно: если вы пишите какое-то недорогое тиражируемое ПО, типа форума, для которого важна распространённость хостинга и его цена, то PHP/(Perl, в чуть меньшей степени, мне кажется, но это спорно)+MySQL. Если же разница в стоимости хостинга в 10-15 долларов в месяц пренебрежимо мала -- то всё равно, что именно, что вам будет удобней.
pamir
Дата: 25.08.2006 01:40:44
DocAl
pamir

Все действительно зависит от задач. По мне, (как ораклиста) так слон лучше - он близок к ораклу по идеологии. Вообще не могу себе представить БД без транзакций (в мускуле кажись они появились. Да?)

В MySQL они БЫЛИ уже в 3.23 года 2001, за раньше просто не берусь говорить.

Вот цитата с форума, на сколько ей можно доверять - не знаю.

автор
Действительно, транзакции в MySQL появились лишь недавно. Дело в том, что "родные" таблицы ISAM, MyISAM и HEAP не поддерживают транзакции. Транзакции в MySQL появились лишь, с появлением сторонних таблиц BDB (Berkley DB) и InnoDB (компания Innobase Oy), в версиях 3.23.12 и 3.23.29, соответственно.

18.07.2004

Это я имел ввиду.
DocAl
Дата: 25.08.2006 02:21:29
pamir

автор
Действительно, транзакции в MySQL появились лишь недавно. Дело в том, что "родные" таблицы ISAM, MyISAM и HEAP не поддерживают транзакции. Транзакции в MySQL появились лишь, с появлением сторонних таблиц BDB (Berkley DB) и InnoDB (компания Innobase Oy), в версиях 3.23.12 и 3.23.29, соответственно.

18.07.2004

Это я имел ввиду.

Ну, "недавно" -- понятие растяжимое.)
Могу вам сказать, что 12 мая 2001 года был выпущен релиз 3.23.38, 3.23.12 -- это где-то начало 2000 года, так что в этом тысячелетие MySQL вошёл уже с транзакциями.)
cherny
Дата: 25.08.2006 08:20:38
Anjey aka PM
если интересует именно приложение (WEB Application) тогда вам копать в сторону Java.
Что имелось ввиду под "именно приложение"? Мне не совсем понятно, что вы хотели сказать. Можно ли немного поподробнее?


К слову, хостинг не играет никакой роли, просто потому, что он использоваться не будет. Т.к. приложение хоть и будет с веб-интерфейсом, но оно не будет работать в Интернет.


Anjey aka PM
Насчет слоника -- не хотел я его опускать, он мне самому нравится, но для большинства задач я бы его не использовал.
А для чего вы бы его использовали?


Пока у меня есть следующие аргументы (насколько они справедливы и стоит ли их в серьез учитывать - вопрос открытый):

MySQL-
"больше скорость, меньше дополнительных возможностей"
более распространена чем PostgreSQL
если распространять (насколько я понял, даже бесплатно?) свой продукт, использующий эту базу, то надо будет сделать его Open Source, либо заплатить MySQL AB.

PostrgeSQL-
"меньше скорость, больше дополнительных возможностей"
хуже подходит для постоянно работающих систем (хотя мне это не к чему)
раньше были сложности с работой под Windows(сейчас есть?)


Python-
синтаксис приятнее чем в Perl (много где так пишут, да и я тоже так считаю)
более дорогой хостинг с его поддержкой (как уже было сказано, мне не важно).

Perl-
(встречал пару раз такую мысль) "подходит для разработки одним человеком" - это все тоже к синтаксису, читабельность которого вобщем то тоже имеет значение.