MySQL+Apache+PHP - все еще лучшая связка для небольших приложений?
Под Windows я бы предложил MS SqlExpress + IIS + ASP.NET
конечно, холиворный. там же провокационное слово php
Если ты знаешь PHP, то да. Если не знаешь, то лучше сразу с Python начинать - полезнее будет в жизни
Под Windows я бы предложил MS SqlExpress + IIS + ASP.NETСовсем забыл про это - уже исправился - эта связка вроде как не бесплатна?
Если ты знаешь PHPВообще писать под него не приходилось.
Если не знаешь, то лучше сразу с Python начинать - полезнее будет в жизниА чем полезнее?
И можно полную связку привести?
А чем полезнее? И можно полную связку привести?Ну, язык более перспективный. Это сейчас из свободных языков самый модный, насколько я могу судить. PHP будущего, в общем.
Про покретную связку говорить глупо. Уже давно всё со всем совместимо. Хочешь - юзаешь апач, хочешь - nginx, хочешь PHP, хочешь - Perl, Ruby или Python. Хочешь MySQL, хочешь - PgSQL, firebird или sqlLite.
AMP просто наиболее распространённая в данный момент связка и есть много инструкций по настройке и уже готовые настроенные наборы вроде денвера.
Я бы посоветовал скачать Денвер (www.denwer.ru и если есть желание разобраться с питоном, то к нему же пакет с питоном, а потом копать в сторону Django (это фреймворк питоновый для веба, хороший). Если желания нет, то купить книжку Котерова по PHP и не париться.
К ней даже можно добавить Visual Web Developer.
Я бы посоветовал скачать Денвер (www.denwer.ru и если есть желание разобраться с питоном, то к нему же пакет с питоном, а потом копать в сторону Django (это фреймворк питоновый для веба, хороший).
Скачал, буду разбираться
Только вот сразу такой вопрос - там написано про
Эмулятор sendmail и SMTP-сервера (отладочная «заглушка» на localhost:25, складывающая приходящие письма в /tmp в формате .eml); поддерживается работа совместно с PHP, Perl, Parser и т.д.- то есть там есть средства генерации и посылки почты? Или только заглушки? И будет ли это работать с Питоном?
есть средства генерации и посылки почты?
в django есть
ps: в stdlib питона есть, но не такие удобные
djangoВсе таки он еще бета.
Хотя посмотреть стоит, спасибо.
п.с.: что-то судя по тому, что предлагают скачивать, оно только под *никс
или на самом деле ставится?
Я бы посоветовал скачать Денвер (www.denwer.ru)
Что кстати со страницы расширений стоит скачать (кроме АктивПитона конечно)?
что-то судя по тому, что предлагают скачивать, оно только под *никсоно - под Python, Python - есть и под Windows.
Ясно, спасибо, попробую
Как минимум потому что мускуль - ужасное говно.
Только я правильно понимаю, что это все только движки, а среду программирования того, что на них крутится (БД, Питон) надо ставить отдельно?
Что бы такое взять для Питона?
Как минимум потому что мускуль - ужасное говно.
А если это будет Firebird/PostgreSQL?
Как минимум потому что мускуль - ужасное говно.А разумные аргументы есть ?
По сравнению с тем же PostgreSQL у MySQL ни одного плюса, сплошные минусы.
Как раз порылся в инете на предмет выбора базы и остановился на двух вариантах: Firebird и PostgreSQL.
Но немного подумав выбрал последний
Есть.Это конечно сильный аргумент.
По сравнению с тем же PostgreSQL у MySQL ни одного плюса, сплошные минусы.
Наверное тебе это рассказал "могучий специалист по Postgre".
У нас сейчас в основном используется PostgreSQL+Apache+PHP, вроде пока справляются, но PHP показал себя говном.
Нет, что вы - всё сами. Раньше тоже пользовались MySQL и не знали, что можно по-другому.
У нас сейчас в основном используется PostgreSQL+Apache+PHP, вроде пока справляются, но PHP показал себя говном.
Альтернативы уже рассматривали?
Чем не понравился ПХП?
Нет, что вы - всё сами. Раньше тоже пользовались MySQL и не знали, что можно по-другому.
Тоже было бы интересно узнать причины от того, кто на это напоролся?..
Тоже было бы интересно узнать причины от того, кто на это напоролся?..
Если ты собираешься часть логики реализовывать средствами БД, тогда у MySQL очень плохо обстоят дела с тригерами и вложенными запросами (В 4.x их точно не было, появились только в 5.0, но тригеры там были очень ограниченные. Как обстоят дела в 5.1 и 6.0 не знаю)
Если же тебе это не надо, ты собираешься использовать БД только как хранилище (и при этом четко осознаешь, что никакой логики внутри БД у тебя не будет ближайшее время то есть твои обращения к базе будут выглядеть исключительно как "select * from tablename where ...", тогда тебе должно быть абсолютно все-равно на какой БД работать. Быть может MySQL будет немного быстрее. А может и не будет.
Если ты собираешься часть логики реализовывать средствами БД, тогда у MySQL очень плохо обстоят дела с тригерами и вложенными запросами (В 4.x их точно не было, появились только в 5.0, но тригеры там были очень ограниченные. Как обстоят дела в 5.1 и 6.0 не знаю)
Если же тебе это не надо, ты собираешься использовать БД только как хранилище (и при этом четко осознаешь, что никакой логики внутри БД у тебя не будет ближайшее время то есть твои обращения к базе будут выглядеть исключительно как "select * from tablename where ...", тогда тебе должно быть абсолютно все-равно на какой БД работать. Быть может MySQL будет немного быстрее. А может и не будет.
Задачи разные.
Скорее интересует база, которую можно использовать во всех случаях (типа затыкать ей все дыры).
Та же логика в базе никогда не бывает лишней.
Спасибо за мнение
Ну или сюда зайди http://www.enterprisedb.com/products/postgres_plus.do — некоторая готовая сборка Postgres-а.
http://articles.techrepublic.com.com/5100-10878_11-1050671.h...
Человек пишет некоторое сравнение MySQL и PostgreSQL. И в конце приводит пример, когда в одном проекте использовались обе базы, каждая для своих целей
Человек пишет некоторое сравнение MySQL и PostgreSQL. И в конце приводит пример, когда в одном проекте использовались обе базы, каждая для своих целей
дико древняя статья
можешь показать ещё какие-то бенчмарки времён палеозоя, будет не менее информативно
По сравнению с тем же PostgreSQL у MySQL ни одного плюса, сплошные минусы.Я слышал о проблемах у PostgreSQL с масштабируемостью и репликацией. Разработчик из мойкруг.ру жаловался и жалел, что они выбрали PostgreSQL, а не MySQL..
Я слышал о проблемах у PostgreSQL с масштабируемостью и репликацией. Разработчик из мойкруг.ру жаловался и жалел, что они выбрали PostgreSQL, а не MySQL..Если я правильно понял, о чём ты, то этот разработчик не жалел о выборе PostgreSQL, просто пришлось отказаться от репликации (просто потому что таких решений для постгреса нет, только неработающий с восьмой версией pgcluster и какие-то платные дорогие продукты).
Я слышал о проблемах у PostgreSQL с масштабируемостьюыыыыыы? по сравнению с мускулем?
На мой взгляд, все утверждения из этой статьи применимы и в настоящий момент.
Я слышал о проблемах у PostgreSQL с масштабируемостью и репликацией. Разработчик из мойкруг.ру жаловался и жалел, что они выбрали PostgreSQL, а не MySQL..
Если я правильно понял, о чём ты, то этот разработчик не жалел о выборе PostgreSQL, просто пришлось отказаться от репликацииЛогика от пенартура на forum.local
Скоро дойдёт до того что разработчик радовался как дитя.
Вакуум из постгреса уже откачивать не надо, как я слышал.
— MySQL не может внести никакие изменения в структуру таблицы, не скопировав все данные. Никакие — это в том числе навесить или удалить индекс!
— Уж не говоря о том, что нельзя навесить индекс без блокировки таблицы.
— в MySQL нет частичных индексов
— MySQL не понимает (или фигово понимает что одинаковые вложенные подзапросы выполнять надо 1 раз. В результате приходится разбивать запрос на несколько, что неестественно.
— MySQL умеет делать поиск по a LIKE 'blalba%' с использованием индекса, но не умеет делать с использованием этого же индекса JOIN.
— В MySQL нет check'ов, в поле типа date разрешён бред типа 0000-00-00, а в поле типа ENUM может оказаться недопустимое значение
— наконец, mysqldump в режиме совместимости с postgresql выдаёт тяжкий бред, одинаково далёкий от стандарта, постгреса и луны.
я на работе накатал файлец претензий к MySQL, но, к сожалению, довольно твёрдо решил с работы в форуме не сидеть. Удалённого доступа на рабочий комп у меня нет, постараюсь не забыть переслать домой.
ыыыыыы?Хочешь сказать, что у постгреса есть нормальная поддержка репликации, или что отсутствие таковой не есть проблема масштабируемости, или ты хочешь сказать нечто иное?
В общем всем спасибо за участие и особое спасибо за ценные советы
Оставить комментарий
durka82
Такой вот полупровокационный вопрос получился, но просьба эмоциям не поддаваться, а аргументироватьОсновные критерии:
Скорость и эффективность разработки(в том числе наличие продвинутых средств разработки)
Безопасность и надежность решений
С производительностью и так проблем быть не должно (ведь в первую очередь это зависит от БД)
Насчет определения "небольших приложений" - это порядка 10-ка одновременно работающих пользователей и порядка нескольких 10-ков тысяч записей в БД.
Спасибо за внимание
п.с.: вообще под вин, но данная связка вроде как переносима (и это плюс, так как *никс как рабочая лошадка рассматривается)
п.п.с.: и еще забыл про главное - фришность (бесплатность всех(ну разве что кроме сред разработки ) составляющих)