Python-сообщество

рад/жаль, что немогу поддержать дискуссию, так до холивара совсем рядом . Не? Я просто просил помочь определиться с фреймворком исходя из моей задачи - рекомендательный сервис. Мне кажется, что некоторые советы давались без общего представления о проблеме. Например, мне очень нравится один такой сервис - ИМХОнет.ру, да и вообще тысячи их. Только мы будем рекомендовать досуг. Мне кажется, что эта задача совсем не типовая, если я возьму джангу, то слишком многое придется переделывать в самой джанге. Я прав?

Почему пирамиды?

• поддержка python 3

• мощный, подходит для любых задач

• гибкий, но не настолько гибкий как микрофреймворки

• SQLAlchemy, которая показалась мне лучшей ОРМ

• хорошая оф. документация. Джанговская мне не понравилась, хотя она есть даже на русском
  

Правильное ли у меня сложилось представление?

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

Также был совет использовать монго. Давно хочу, но я не понимаю в каких ситуациях она лучше. Чтение обзоров ни к чему не приводит, они слишком заангажированы либо в сторону монги, либо в противоположную сторону. Когда брать надо ее?

Отредактировано KsimMiloff (Ноя. 28, 2013 08:31:24)

KsimMiloff
гибкий, но не настолько гибкий как микрофреймворки

На вид он достаточно гибкий, он как микро-фреймворк + пачка абстрактных модулей, которые может будете использовать, а может и нет. Некоторые модули может замените более удобными (это как с комментариями в джанго).

KsimMiloff
Также был совет использовать монго.

Для сравнения можете попробовать сделать мини-туду приложение или блог/вики, на sql и монго.
Если система отчетная или нужны “топорные” транзакции, то (p/my)sql удобнее. В других проектах монга может быть лучше.
Например такие запросы как “получить все кометарии моих друзей” или “получить статьи в которых одновременно есть теги а,б,в” на монге делаются в один запрос, когда на mysql это затруднительно или не возможно.

поддержка python 3

Да.

мощный, подходит для любых задач

Да.

гибкий, но не настолько гибкий как микрофреймворки

Тут o7412369815963 правильно сказал. Расширю: что пирамида ни в коей мере не задаёт архитектуру проекта.

SQLAlchemy, которая показалась мне лучшей ОРМ

Да.

хорошая оф. документация. Джанговская мне не понравилась, хотя она есть даже на русском

Нет. Всё-таки джанговская документация будет получше. Но зато код у пирамиды куда понятнее и документированние, читать его – одно удовольствие!

Для сравнения можете попробовать сделать мини-туду приложение или блог/вики, на sql и монго.

Это никак не покажет ни мощь монго, ни его слабые стороны. Чтобы в него въехать, нужно начать мыслить в её терминах, и забыть про термины SQL, а на это нужно время, которое зависит от гибкости мышления конкретного программиста.
Объективно, монга не везде и не всегда хороша.

Тут есть кое какой треп про pyramid vs bottle.
Там есть неплохой коммент, типа “фреймворк - это 5% от проекта, которые чуть что можно заменить”, т.е. особой разницы нет.

o7412369815963
Например такие запросы как “получить все кометарии моих друзей” или “получить статьи в которых одновременно есть теги а,б,в” на монге делаются в один запрос, когда на mysql это затруднительно или не возможно.

Берусь написать эти 2 запроса для пари. Моя ставка $1000. Согласен на коэффициент 1 к 1 ;)

ZZZ
Нет. Всё-таки джанговская документация будет получше. Но зато код у пирамиды куда понятнее и документированние, читать его – одно удовольствие!

а может именно это я и имел в виду

ZZZ
Это никак не покажет ни мощь монго, ни его слабые стороны. Чтобы в него въехать, нужно начать мыслить в её терминах, и забыть про термины SQL, а на это нужно время, которое зависит от гибкости мышления конкретного программиста.
Объективно, монга не везде и не всегда хороша.

Согласен с вами. Во всех обзорах, где монго побеждало, стронники sql кричали “ты неправильно настроил базу” и наоброт, где побеждал sql тоже самое говорили о монго.
Лично я склоняюсь к sql + ORM, потому что опыт есть.

а можете подкинуть где есть большой проект на питоне и чистой монге(з) ? я нашел только quokka но он на mongoengine https://github.com/pythonhub/quokka/blob/master/quokka/core/db.py#L7

Lexander
Берусь написать эти 2 запроса для пари. Моя ставка $1000. Согласен на коэффициент 1 к 1 ;)

Эти запросы уже написаны в комментах на хабре:
http://habrahabr.ru/company/jelastic/blog/166845/#comment_5895907
http://habrahabr.ru/company/jelastic/blog/166845/#comment_5897325
другое дело что на mysql он работает 30 мин против 0,1 сек на монго (примерно, по памяти), что не является решением.

Singularity
можете подкинуть где есть большой проект на питоне и чистой монге(з) ? я нашел только quokka но он на mongoengine

А зачем? В серьезном проекте все равно должна быть какая-то оболочка (модель). Я например использую самописную.

o7412369815963
другое дело что на mysql он работает 30 мин

Я тут опять могу написать предложение о пари, но какой в этом смысл, если вы снова “забудете”, что фигню сморозили постом ранее и останетесь в тени своего стереотипа о SQL? ;)

Запрос на “миллионе объектов” (с Хабра) в рамках поставленной задачи уже достаточно смешно звучит для реальной продакшн системы и вызывает сомнения в компетентности проектировщика.
Дело тут совсем не в количестве.

ЗЫ
У меня системы работают как на SQL, так и на NoSQL, в том числе на Монге.
Кстати, производительность Монги для определенного вида операций делает ее замечательным и безальтернативным (отсутствие конкурентов) выбором, например, для продвинутого кеша, по которому можно делать выборки.
Но я, например, никогда ее не посоветую для транзакционных бизнес-операций из-за eventual consistency.

Lexander
Но я, например, никогда ее не посоветую для транзакционных бизнес-операций из-за eventual consistency.

Я про то же выше написал:

o7412369815963
Если система отчетная или нужны “топорные” транзакции, то (p/my)sql удобнее.

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

Хотя, если философски порассуждать, то и “eventual consistency” для бизнес операций может быть норм.

Lexander
Дело тут совсем не в количестве.

Говорите загадками, давайте поподробнее, (возможно) у меня уже готов ответ ;)

Lexander
Я тут опять могу написать предложение о пари

Ваше “пари” - “брать на понт”, вместо конструктивного ответа.

Lexander
что фигню сморозили постом ранее

Необоснованый “наезд”, скорее вы по своему интерпретировали мысль которую я вложил в предложение, (и не надо придираться к словам).

Lexander
останетесь в тени своего стереотипа о SQL? ;)

Ничего подобного, я выбираю “инструмент от задачи” (+ факторы). Например в прошлом проекте у меня используется и монга и mysql.