Думал - написать или нет холиварное сообщение… :)
Считаю что для веба удобней (перспективней) использовать mongodb (nosql) чем mysql/psql (в 98% случаях), нет проблем с миграцией и пр. Поэтому в свое время отмел джанго. Т.к. орм джанги уже не поюзать, а без орм там брать нечего, вместо шаблонов - jinja, роутинг есть во всех других фреймворках, часть плагинов не заведется, к тому же, по отзывам, действительно полезных плагинов мало.

ЗЫ: это пост не про nosql vs sql

Может быть вы говорите о больших проектах. Честно говоря, не понимаю, как mongo может быть удобней для разработки маленьких сайтов, когда все данные умещаются на одной машине и нету каких-то чрезмерных нагрузок. Реляционки дают целостность данных из коробки, а в монге надо реализовывать этот самому в ORM слое. Я себя чувствую спокойно, когда знаю. что данные лежат в реляционной схеме и как-минимсум удовлетворяют всем типам колонок таблиц и foreign key связям. Монго я использую для парсинга, во-время парсинга часто я не знаю будущую схему данных и очень часто её изменяю в процессе разработки парсера. Если же проект по парсингу долговременный опять же вижу смысл складывать данные в реляционку.

o7412369815963
Считаю что для веба удобней (перспективней) использовать mongodb (nosql) чем mysql/psql (в 98% случаях), нет проблем с миграцией и пр.

На средних и больших проектах миграция (и версионность) всегда есть.
Только в случае NoSQL ее нужно делать средствами приложения - та еще морока.
Исключение - чистые web-сервисы.
Но если вы добавите к ним хотя бы мобильный клиент, зоопарк версий тут как тут.

lorien
Может быть вы говорите о больших проектах.

Скорее о небольших и коротких.
Если хотите, Монго имеет 3 ключевых особенности, за что ее любят:
1. быстрый старт разработки
2. масштабируемость из коробки
3. мода :)
Как вы понимаете, это далеко, например, от надежности и целостности.
Отсюда и модель использования.

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

Как я выше заметил, быстрый старт.

lorien
однажды я даже дошёл до того, чтобы делать миграции алембиком. Алембик мне менее удобных показался, чем south, он не мог автоматически делать простые миграции.

Возможно, это было еще во время sqlalchemy-migrate как основного инструмента миграция, а Алембик был еще в очень зачаточном состоянии.

ОРМ - это отдельная песня и пока еще слова ее не сложились окончательно.
Всем ОРМ еще расти и расти до нормальной прослойки между СУБД и программой.
Это и джавовских ОРМ касается, хотя там всегда деньги на развитие были - все таки корпоративный стандарт.

Однако, сравнение SQLAlchemy и django orm равно как и south с Alembic по фичам в данном топике, мне кажется, смысла не имеет.

lorien
Ну и в целом sqlalchemy я так и не осилил, для уровня сложности моих задач целиком и полностью подходит django orm, причём я не говорю только о веб-сайтах, о системах парсинга данных из сети тоже говорю.

Все верно, я тоже выбираю инструмент исходя из задачи, а не количества возможностей, хотя это тоже важный критерий для систем с перспективой развития.
Поэтому и заметил в начале нашей беседы, что роль архитектуры повышается при росте системы.

SQLAlchemy становится актуальна, когда бизнес-требования к системе уже перешагнули границы простых запросов, но еще не дошли до чистого SQL.
Чем больше кросс-связанность агрегированных данных (сложность запросов, для планировщика запросов СУБД, при росте количества таблиц и добавлении агрегирующих функций), которые нужно получать пользователям, тем больше мы движемся в сторону чистого SQL.
А он нужен только на этапе оптимизации, когда стандартные решения ОРМ уже ничего не могут сделать или нужен функционал спец средств СУБД типа хранимых процедур, сложных прав доступа или pivot данных.

> Считаю что для веба удобней (перспективней) использовать mongodb (nosql) чем mysql/psql (в 98% случаях), нет проблем с миграцией и пр.

От миграций никуда не уйдёшь. Есть два варианта:
1) Или вы в конкретный момент времени имеете НЕЧТО в вашей mongodb, не имея возможности сказать какие объекты одной коллекции какими полями обладают (и какие в них данные)
2) Или вы всё же поддерживаете целостность данных, а это и называется миграциии.

Возможно, это было еще во время sqlalchemy-migrate как основного инструмента миграция, а Алембик был еще в очень зачаточном состоянии.

Это было где-то полтора года назад, если ничего не путаю.

О вопросе архитектуры: http://django-vanilla-views.org/
Навскидку, неплохо получилось.

lorien
2) Или вы всё же поддерживаете целостность данных, а это и называется миграциии.

Ясно, тогда есть.
У меня в одном из проектов - это проходит плавно. Добавляем атрибут в тип - объекты при этом не меняем, этот атрибут будет появляться (постепенно) в тех объектах с которыми идет работа (чаще при записи данных). Т.е. получается миграция идет сама по себе…

Lexander
Если хотите, Монго имеет 3 ключевых особенности, за что ее любят:
1. быстрый старт разработки

и не только старт, но и в процессе разработки, конечно время экономиться на мелочах, но суммарно оно чувствуется.
я бы ещё добавил в список - 3. некоторые полезные фичи которых нет во многих других базах из коробки.

Похоже я понял почему вы предпочитаете sql - для них уже есть куча разных тулзов, орм-ов и пр. Т.е. речь не про саму БД, а про способы её использования.

Lexander
Только в случае NoSQL ее нужно делать средствами приложения - та еще морока.

Не знаю про что вы, у меня все просто и легко с миграцией, приведите жизненный пример.

У меня есть движок - что-то типа “админка + орм” под монгу. Текущий проект для крупной компании: bpms + call-center + olap + разные небольшие приложения. В этом движке типы (модели) настраиваются в админке, на основе типа создаются объекты, так же объект может быть типом, на основе которого…
Один случай: начальник-разработчик просыпается с утра с гениальной идеей которую никто не может понять, поэтому берет, накидывает типы, объекты, я привязываю в коде пару ф-ий - прототип готов.
Ещё пример - опытный пользователь, хочет добавить в справочник “пользователи”, какие-то атрибуты, если есть доступ на тип - заходит в админку и мышкой накидывает атрибуты/изменяет тип - в этот же момент (без тяжелых перемалываний базы), все пользователи начинают работать с “обновленным типом”.

На данный момент в текущем проекте около 400 типов данных, куча типов с множественным наследованием, т.к. каждый бизнес процесс порождает свой вид объектов со своими атрибутами, то он является и типом и объектом одновременно.

Это может звучать страшновато, но по настоящему - это мега удобно и просто (для меня). Сделать это в реляционной базе - думаю “можно повеситься”

Lexander
роль архитектуры повышается при росте системы.

С этим согласен. (если я правильно понял термин)
- За 2 года разработки крупного проекта, выработал принципы и инструменты, которые чем то похожи на аспектно-оринтированное программирование. В результате с ростом проекта, скорость разработки почти не падает, как было ранее. Хотя для маленьких проектов она выглядит как ненужные костыли.

Ребята, спасибо за обсуждение! Подскажите, с какой IDE лучше начать и какой материал в каком порядке изучать на ваш взгляд лучше?

o7412369815963
Похоже я понял почему вы предпочитаете sql - для них уже есть куча разных тулзов, орм-ов и пр. Т.е. речь не про саму БД, а про способы её использования.

Не совсем. Инструмент должен удовлетворять потребностям.
Так, для небольших проектов вполне хватает django-orm.
Мне и в голову не придет делать кеширование на sql! :D
Последнее ваше предложение из цитаты - вот почему.
Просто я сталкиваюсь больше с крупными проектами.
При этом для “домашних” проектов использую и NoSQL, и django :)

o7412369815963
Не знаю про что вы, у меня все просто и легко с миграцией, приведите жизненный пример.

А я его сразу и указал: приложения на мобильных.
Когда много удаленных обособленных клиентов, на обновление которых вы повлиять не можете, вы вынуждены писать так, чтобы учитывалось возможное изменение структуры данных.
Хорошо, когда можно самому протокол выбрать - protobuf решает эту задачу версионности структур данных из коробки.
А если данные передаются в json?

o7412369815963
Сделать это в реляционной базе - думаю “можно повеситься”

Смотря в какой.
PostgreSQL имеет все возможности для работы с такими объектами, сериализуются в json.
При этом сохраняются плюшки типа ACID, специальных для json нативных функций и проверки данных - на битый json Postgre поругается.

Invis1ble
Подскажите, с какой IDE лучше начать

На первых порах, пока изучаете технологии, я бы IDE не рекомендовал. Пару недель поработайте в продвинутом редакторе.
Рекомендую Sublime Text с плагинами для python. Сейчас уже сформировался набор плагинов, который можно нагуглить. Sublime Text из коробки даже проекты умеет создавать и работать с ними.

Позже - Pycharm - это уже полноценная IDE. Она платная. Но денег своих стоит.
Считаю ее лучшей IDE для Питона в целом, особенно для web-разработки.
Из бесплатных вроде недавно вышедший PyDev на базе Эклипса хвалят. Но именно эту версию я не видел и не пробовал. Прошлые версии ушли в туман как только попробовал PyCharm.