MySQL+Apache+PHP - все еще лучшая связка для небольших приложений?

durka82

Такой вот полупровокационный вопрос получился, но просьба эмоциям не поддаваться, а аргументировать ;)
Основные критерии:
Скорость и эффективность разработки(в том числе наличие продвинутых средств разработки)
Безопасность и надежность решений
С производительностью и так проблем быть не должно (ведь в первую очередь это зависит от БД)
Насчет определения "небольших приложений" - это порядка 10-ка одновременно работающих пользователей и порядка нескольких 10-ков тысяч записей в БД.
Спасибо за внимание :)
п.с.: вообще под вин, но данная связка вроде как переносима (и это плюс, так как *никс как рабочая лошадка рассматривается)
п.п.с.: и еще забыл про главное - фришность (бесплатность всех(ну разве что кроме сред разработки :)) составляющих)

agaaaa

Какой-то холиварный вопрос.
Под Windows я бы предложил MS SqlExpress + IIS + ASP.NET

Bibi

конечно, холиворный. там же провокационное слово php

sbs-66

Если ты знаешь PHP, то да. Если не знаешь, то лучше сразу с Python начинать - полезнее будет в жизни

durka82

Под Windows я бы предложил MS SqlExpress + IIS + ASP.NET
Совсем забыл про это - уже исправился - эта связка вроде как не бесплатна?

durka82

Если ты знаешь PHP
Вообще писать под него не приходилось.
Если не знаешь, то лучше сразу с Python начинать - полезнее будет в жизни
А чем полезнее?
И можно полную связку привести?

sbs-66

А чем полезнее? И можно полную связку привести?
Ну, язык более перспективный. Это сейчас из свободных языков самый модный, насколько я могу судить. PHP будущего, в общем.
Про покретную связку говорить глупо. Уже давно всё со всем совместимо. Хочешь - юзаешь апач, хочешь - nginx, хочешь PHP, хочешь - Perl, Ruby или Python. Хочешь MySQL, хочешь - PgSQL, firebird или sqlLite.
AMP просто наиболее распространённая в данный момент связка и есть много инструкций по настройке и уже готовые настроенные наборы вроде денвера.
Я бы посоветовал скачать Денвер (www.denwer.ru и если есть желание разобраться с питоном, то к нему же пакет с питоном, а потом копать в сторону Django (это фреймворк питоновый для веба, хороший). Если желания нет, то купить книжку Котерова по PHP и не париться.

agaaaa

Эта связка бесплатна.
К ней даже можно добавить Visual Web Developer.

durka82

Я бы посоветовал скачать Денвер (www.denwer.ru и если есть желание разобраться с питоном, то к нему же пакет с питоном, а потом копать в сторону Django (это фреймворк питоновый для веба, хороший).

Скачал, буду разбираться :)
Только вот сразу такой вопрос - там написано про
Эмулятор sendmail и SMTP-сервера (отладочная «заглушка» на localhost:25, складывающая приходящие письма в /tmp в формате .eml); поддерживается работа совместно с PHP, Perl, Parser и т.д.
- то есть там есть средства генерации и посылки почты? Или только заглушки? И будет ли это работать с Питоном?

pilot

 
есть средства генерации и посылки почты?

в django есть
ps: в stdlib питона есть, но не такие удобные

durka82

django
Все таки он еще бета.
Хотя посмотреть стоит, спасибо.
п.с.: что-то судя по тому, что предлагают скачивать, оно только под *никс :(
или на самом деле ставится?

durka82

Я бы посоветовал скачать Денвер (www.denwer.ru)

Что кстати со страницы расширений стоит скачать (кроме АктивПитона конечно)?

klyv

что-то судя по тому, что предлагают скачивать, оно только под *никс
оно - под Python, Python - есть и под Windows.

durka82

Ясно, спасибо, попробую :)

kruzer25

Нет, конечно.
Как минимум потому что мускуль - ужасное говно.

durka82

Попробовал, прикольно :)
Только я правильно понимаю, что это все только движки, а среду программирования того, что на них крутится (БД, Питон) надо ставить отдельно?
Что бы такое взять для Питона?

durka82

Как минимум потому что мускуль - ужасное говно.

А если это будет Firebird/PostgreSQL?

NAIL

Как минимум потому что мускуль - ужасное говно.
А разумные аргументы есть ?

kruzer25

Есть.
По сравнению с тем же PostgreSQL у MySQL ни одного плюса, сплошные минусы.

durka82

То есть связка PostgreSQL+Apache+Python одобряется?
Как раз порылся в инете на предмет выбора базы и остановился на двух вариантах: Firebird и PostgreSQL.
Но немного подумав выбрал последний :)

NAIL

Есть.
По сравнению с тем же PostgreSQL у MySQL ни одного плюса, сплошные минусы.
Это конечно сильный аргумент.
Наверное тебе это рассказал "могучий специалист по Postgre".

kruzer25

У нас сейчас в основном используется PostgreSQL+Apache+PHP, вроде пока справляются, но PHP показал себя говном.

kruzer25

Нет, что вы - всё сами. Раньше тоже пользовались MySQL и не знали, что можно по-другому.

durka82

У нас сейчас в основном используется PostgreSQL+Apache+PHP, вроде пока справляются, но PHP показал себя говном.

Альтернативы уже рассматривали?
Чем не понравился ПХП?
Нет, что вы - всё сами. Раньше тоже пользовались MySQL и не знали, что можно по-другому.

Тоже было бы интересно узнать причины от того, кто на это напоролся?..

Sharp

Тоже было бы интересно узнать причины от того, кто на это напоролся?..

Если ты собираешься часть логики реализовывать средствами БД, тогда у MySQL очень плохо обстоят дела с тригерами и вложенными запросами (В 4.x их точно не было, появились только в 5.0, но тригеры там были очень ограниченные. Как обстоят дела в 5.1 и 6.0 не знаю)
Если же тебе это не надо, ты собираешься использовать БД только как хранилище (и при этом четко осознаешь, что никакой логики внутри БД у тебя не будет ближайшее время то есть твои обращения к базе будут выглядеть исключительно как "select * from tablename where ...", тогда тебе должно быть абсолютно все-равно на какой БД работать. Быть может MySQL будет немного быстрее. А может и не будет.

durka82

Если ты собираешься часть логики реализовывать средствами БД, тогда у MySQL очень плохо обстоят дела с тригерами и вложенными запросами (В 4.x их точно не было, появились только в 5.0, но тригеры там были очень ограниченные. Как обстоят дела в 5.1 и 6.0 не знаю)
Если же тебе это не надо, ты собираешься использовать БД только как хранилище (и при этом четко осознаешь, что никакой логики внутри БД у тебя не будет ближайшее время то есть твои обращения к базе будут выглядеть исключительно как "select * from tablename where ...", тогда тебе должно быть абсолютно все-равно на какой БД работать. Быть может MySQL будет немного быстрее. А может и не будет.

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

Sharp

Тогда действительно смотри в сторону Postgres-а.
Ну или сюда зайди http://www.enterprisedb.com/products/postgres_plus.do — некоторая готовая сборка Postgres-а.

Sharp

http://articles.techrepublic.com.com/5100-10878_11-1050671.h...
Человек пишет некоторое сравнение MySQL и PostgreSQL. И в конце приводит пример, когда в одном проекте использовались обе базы, каждая для своих целей ;)

Marinavo_0507

дико древняя статья

Fmouse

можешь показать ещё какие-то бенчмарки времён палеозоя, будет не менее информативно :D

karkar

По сравнению с тем же PostgreSQL у MySQL ни одного плюса, сплошные минусы.
Я слышал о проблемах у PostgreSQL с масштабируемостью и репликацией. Разработчик из мойкруг.ру жаловался и жалел, что они выбрали PostgreSQL, а не MySQL..

kruzer25

Я слышал о проблемах у PostgreSQL с масштабируемостью и репликацией. Разработчик из мойкруг.ру жаловался и жалел, что они выбрали PostgreSQL, а не MySQL..
Если я правильно понял, о чём ты, то этот разработчик не жалел о выборе PostgreSQL, просто пришлось отказаться от репликации (просто потому что таких решений для постгреса нет, только неработающий с восьмой версией pgcluster и какие-то платные дорогие продукты).

Fmouse

Я слышал о проблемах у PostgreSQL с масштабируемостью
ыыыыыы? по сравнению с мускулем?

Sharp

И что с того, что статья древняя?
На мой взгляд, все утверждения из этой статьи применимы и в настоящий момент.

NAIL

Я слышал о проблемах у PostgreSQL с масштабируемостью и репликацией. Разработчик из мойкруг.ру жаловался и жалел, что они выбрали PostgreSQL, а не MySQL..

Если я правильно понял, о чём ты, то этот разработчик не жалел о выборе PostgreSQL, просто пришлось отказаться от репликации
Логика от пенартура на forum.local
Скоро дойдёт до того что разработчик радовался как дитя.

Marinavo_0507

Список фичей mysql сильно увеличился, за счёт, естественно, простоты.
Вакуум из постгреса уже откачивать не надо, как я слышал.

hwh2010

Рассказываю, какие проблемы у меня возникают с MySQL при работе с большими объёмами данных
— MySQL не может внести никакие изменения в структуру таблицы, не скопировав все данные. Никакие — это в том числе навесить или удалить индекс!
— Уж не говоря о том, что нельзя навесить индекс без блокировки таблицы.
— в MySQL нет частичных индексов
— MySQL не понимает (или фигово понимает что одинаковые вложенные подзапросы выполнять надо 1 раз. В результате приходится разбивать запрос на несколько, что неестественно.
— MySQL умеет делать поиск по a LIKE 'blalba%' с использованием индекса, но не умеет делать с использованием этого же индекса JOIN.
— В MySQL нет check'ов, в поле типа date разрешён бред типа 0000-00-00, а в поле типа ENUM может оказаться недопустимое значение
— наконец, mysqldump в режиме совместимости с postgresql выдаёт тяжкий бред, одинаково далёкий от стандарта, постгреса и луны.
я на работе накатал файлец претензий к MySQL, но, к сожалению, довольно твёрдо решил с работы в форуме не сидеть. Удалённого доступа на рабочий комп у меня нет, постараюсь не забыть переслать домой.

karkar

ыыыыыы?
Хочешь сказать, что у постгреса есть нормальная поддержка репликации, или что отсутствие таковой не есть проблема масштабируемости, или ты хочешь сказать нечто иное?

durka82

В общем всем спасибо за участие и особое спасибо за ценные советы :cool:
Оставить комментарий
Имя или ник:
Комментарий: