django > ror? куда пойти джангисту

Сразу с ходу такое писать не стану, перемудрю или недомудрю.
А так - да, m/r здесь проще всего. Можно уложиться в один запрос.
И да, я не «фанат монго». Фанаты это такие люди, которые используют что-то даже когда вся общественность признала что это плохо.

>других причин использовать noSQL просто нет
Как-будто столько информации и всё в пустую... Ну разве динамичность документов, скорость работы и остальное - не плюсы?

Что, простите?

>динамичность документов
отсутствие схемы бд и как следствие невозможность манипулировать обьектами бизнес логики а только мапами.

скорость работы

спорно.

и остальное

безусловно.

Нет, я пока плюсов не вижу.

ну как бы вот и видно, что кверей Вы для монго не писали.

>отсутствие схемы бд и как следствие невозможность манипулировать обьектами бизнес логики а только мапами.
Я всё ещё думаю что ты либо ничего не хочешь видеть, либо просто слеп.
Понимаешь, схема нужна просто для валидации, проверки. Это всё успешно выполняют програмные слои вроде монгоида, монгокита, монгоэнжина или чего ещё. Всё это есть и работает быстрее SQL и ORM для него.
Объектами бизнес-логики очень легко манипулировать даже без схем, к слову.
Наличие «жёстких» схем просто противоречит динамичности. Ты просто пожаловался на том что «mongodb это не SQL», иными словами.

спорно.

Слушай, если ты просто потроллить пришёл, то не трать моё время, оно не так дёшево.

Имею документы с 3+ листами, индексы работают. ЧЯДНТ?

в кверях встречается хотя два одновременно листовых поля? можно попросить результаты findOne() и explain() если не NDA

>Более сложная логика? Возможность изменения структуры, более гибкие запросы дают возможность реализовать сколь угодно сложную логику. >Скорость БД позволяет посмеяться над реализацией такой логики через SQL.

Я с noSQL знаком по большей части только теоретически. Мне вот интересно как будет решена подобная задача на noSQL:

Это реальная задача с которой я сейчас работаю, только упрощенная (я сразу опишу ее как она решена средствами postgreSQL).

1. Есть таблица с описаниями продажи бизнеса. 2. Источников из которых берутся данные - множество и их формат мы контролировать не можем. 3. Нам нужен быстрый full-text поиск по тексту из описания и названия, с ранжированием результатов и возможностью изменить веса ранжирования при необходимости. 4. Любые поля могут быть в любой момент изменены администратором системы или автоматически в результате допустим действия скрипта.

Допустим у нас в таблице есть такие поля: название, описание, стоимость, стоимость_числовая, страна. К каждой записи может быть привязано от 0 до X изображений и дополнительных описаний. (Стоимость - поле текстовго типа, т.к. оно может содержать например такое значение - «About 10k», а стоимость_числовая расчитывается по определнными правилам из стоимость).

Вот на джанге+постгрес все это решается стандартными средствами очень быстро, просто и надежно. full-text search на название+описание+ ранжирование. trigger на insert/update для заполнения поля стоимость_числовая.

Валидация всех данных по установленным констрейнтам (есть кстати такая штука в noSQL решениях?).

>Валидация всех данных по установленным констрейнтам (есть кстати такая штука в noSQL решениях?).

А, кстати, зачем тебе валидация в БД, если у тебя джанга валидирует? Или у тебя только в БД?

>А, кстати, зачем тебе валидация в БД, если у тебя джанга валидирует? Или у тебя только в БД?

Джанга проверят только тип поля. Более сложные констрейнты работают на уровне СУБД. Все проверять на уровне приложения - будут дикие тормоза.

в кверях встречается хотя два одновременно листовых поля? можно попросить результаты findOne() и explain() если не NDA

Специально проверил. Все работает.

> db.objects.find({x : 5});
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145e7"), "x" : 5, "j" : 1, "names" : [ 1, 2, 3 ], "surnames" : [ 10, 11, 12 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145e8"), "x" : 5, "j" : 2, "names" : [ 2, 4, 6 ], "surnames" : [ 11, 12, 13 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145e9"), "x" : 5, "j" : 3, "names" : [ 3, 6, 9 ], "surnames" : [ 12, 13, 14 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145ea"), "x" : 5, "j" : 4, "names" : [ 4, 8, 12 ], "surnames" : [ 13, 14, 15 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145eb"), "x" : 5, "j" : 5, "names" : [ 5, 10, 15 ], "surnames" : [ 14, 15, 16 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145ec"), "x" : 5, "j" : 6, "names" : [ 6, 12, 18 ], "surnames" : [ 15, 16, 17 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145ed"), "x" : 5, "j" : 7, "names" : [ 7, 14, 21 ], "surnames" : [ 16, 17, 18 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145ee"), "x" : 5, "j" : 8, "names" : [ 8, 16, 24 ], "surnames" : [ 17, 18, 19 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145ef"), "x" : 5, "j" : 9, "names" : [ 9, 18, 27 ], "surnames" : [ 18, 19, 20 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145f0"), "x" : 5, "j" : 10, "names" : [ 10, 20, 30 ], "surnames" : [ 19, 20, 21 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145f1"), "x" : 5, "j" : 11, "names" : [ 11, 22, 33 ], "surnames" : [ 20, 21, 22 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145f2"), "x" : 5, "j" : 12, "names" : [ 12, 24, 36 ], "surnames" : [ 21, 22, 23 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145f3"), "x" : 5, "j" : 13, "names" : [ 13, 26, 39 ], "surnames" : [ 22, 23, 24 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145f4"), "x" : 5, "j" : 14, "names" : [ 14, 28, 42 ], "surnames" : [ 23, 24, 25 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145f5"), "x" : 5, "j" : 15, "names" : [ 15, 30, 45 ], "surnames" : [ 24, 25, 26 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145f6"), "x" : 5, "j" : 16, "names" : [ 16, 32, 48 ], "surnames" : [ 25, 26, 27 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145f7"), "x" : 5, "j" : 17, "names" : [ 17, 34, 51 ], "surnames" : [ 26, 27, 28 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145f8"), "x" : 5, "j" : 18, "names" : [ 18, 36, 54 ], "surnames" : [ 27, 28, 29 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145f9"), "x" : 5, "j" : 19, "names" : [ 19, 38, 57 ], "surnames" : [ 28, 29, 30 ] }
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145fa"), "x" : 5, "j" : 20, "names" : [ 20, 40, 60 ], "surnames" : [ 29, 30, 31 ] }
>  db.objects.find({x : 6}); 
{ "_id" : ObjectId("4ce8bfa9a72a5acbe47145fb"), "x" : 6, "j" : 1, "names" : [ 1, 2, 3 ], "surnames" : [ 10, 11, 12 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe47145fc"), "x" : 6, "j" : 2, "names" : [ 2, 4, 6 ], "surnames" : [ 11, 12, 13 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe47145fd"), "x" : 6, "j" : 3, "names" : [ 3, 6, 9 ], "surnames" : [ 12, 13, 14 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe47145fe"), "x" : 6, "j" : 4, "names" : [ 4, 8, 12 ], "surnames" : [ 13, 14, 15 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe47145ff"), "x" : 6, "j" : 5, "names" : [ 5, 10, 15 ], "surnames" : [ 14, 15, 16 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe4714600"), "x" : 6, "j" : 6, "names" : [ 6, 12, 18 ], "surnames" : [ 15, 16, 17 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe4714601"), "x" : 6, "j" : 7, "names" : [ 7, 14, 21 ], "surnames" : [ 16, 17, 18 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe4714602"), "x" : 6, "j" : 8, "names" : [ 8, 16, 24 ], "surnames" : [ 17, 18, 19 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe4714603"), "x" : 6, "j" : 9, "names" : [ 9, 18, 27 ], "surnames" : [ 18, 19, 20 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe4714604"), "x" : 6, "j" : 10, "names" : [ 10, 20, 30 ], "surnames" : [ 19, 20, 21 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe4714605"), "x" : 6, "j" : 11, "names" : [ 11, 22, 33 ], "surnames" : [ 20, 21, 22 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe4714606"), "x" : 6, "j" : 12, "names" : [ 12, 24, 36 ], "surnames" : [ 21, 22, 23 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe4714607"), "x" : 6, "j" : 13, "names" : [ 13, 26, 39 ], "surnames" : [ 22, 23, 24 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe4714608"), "x" : 6, "j" : 14, "names" : [ 14, 28, 42 ], "surnames" : [ 23, 24, 25 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe4714609"), "x" : 6, "j" : 15, "names" : [ 15, 30, 45 ], "surnames" : [ 24, 25, 26 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe471460a"), "x" : 6, "j" : 16, "names" : [ 16, 32, 48 ], "surnames" : [ 25, 26, 27 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe471460b"), "x" : 6, "j" : 17, "names" : [ 17, 34, 51 ], "surnames" : [ 26, 27, 28 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe471460c"), "x" : 6, "j" : 18, "names" : [ 18, 36, 54 ], "surnames" : [ 27, 28, 29 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe471460d"), "x" : 6, "j" : 19, "names" : [ 19, 38, 57 ], "surnames" : [ 28, 29, 30 ] }
{ "_id" : ObjectId("4ce8bfa9a72a5acbe471460e"), "x" : 6, "j" : 20, "names" : [ 20, 40, 60 ], "surnames" : [ 29, 30, 31 ] }
> db.objects.ensureIndex({x : 1})
> db.objects.find({x : 5, names : 10, surnames : 21});
{ "_id" : ObjectId("4ce8bf95a72a5acbe47145f0"), "x" : 5, "j" : 10, "names" : [ 10, 20, 30 ], "surnames" : [ 19, 20, 21 ] }
> db.objects.find({x : 5, names : 10, surnames : 21}).explain();
{
	"cursor" : "BtreeCursor x_1",
	"indexBounds" : [
		[
			{
				"x" : 5
			},
			{
				"x" : 5
			}
		]
	],
	"nscanned" : 20,
	"nscannedObjects" : 20,
	"n" : 1,
	"millis" : 0,
	"oldPlan" : {
		"cursor" : "BtreeCursor x_1",
		"indexBounds" : [
			[
				{
					"x" : 5
				},
				{
					"x" : 5
				}
			]
		]
	},
	"allPlans" : [
		{
			"cursor" : "BtreeCursor x_1",
			"indexBounds" : [
				[
					{
						"x" : 5
					},
					{
						"x" : 5
					}
				]
			]
		},
		{
			"cursor" : "BasicCursor",
			"indexBounds" : [ ]
		}
	]
}
> 

> Вот на джанге+постгрес все это решается стандартными средствами очень быстро, просто и надежно. full-text search на название+описание+ ранжирование. trigger на insert/update для заполнения поля стоимость_числовая.

В монго триггеров нет, афаик. Полнотекстовый поиск есть, конечно же.

> отсутствие схемы бд и как следствие невозможность манипулировать обьектами бизнес логики а только мапами.

Во многих ситуациях это очень даже плюс.

спорно.

инсерты и апдейты безумно быстры, потому что не ACID, SQL в любом случае тут проиграет, и чтение быстрее.

>Полнотекстовый поиск есть, конечно же.

С ранжированием?

чтение быстрее

Надо полагать быстрее на простых «plain» запросах.
А что с более менее сложными запросами?

(я сам не знаю, поэтому и спрашиваю. Давно хочу один проект на noSQL перевести, но что-то руки не доходят).

>потому что не ACID, SQL в любом случае тут проиграет

Как следствие модификация сколько-то нетривальных данных легко может нарушить консистентность базы. Просто прекрасно. Это, конечно, очень расширяет ее применение.

> (есть кстати такая штука в noSQL решениях?)

В документо-ориентированных нет. По определению. Потому что там вся фишка в динамичности.

>NoSQL это собирательный образ всех СУБД, которые не используют SQL.

Именно NoSQL ставится как противник SQL, как то, что должно его заменить.

Учитывая то, что NoSQL расшифровывается как Not Only SQL (то есть как дополнение), твое мнение в этом вопросе действительно авторитетно.

>Кстати, SF.net используют TG2 с mongodb.

SF.net это соурсфордж? Они же на php были отродясь, разве нет?

правильно, а я о чем? индекс подхватился только по первому полю. По двум другим идекс не подхватился (если был)

> правильно, а я о чем? индекс подхватился только по первому полю. По двум другим идекс не подхватился (если был)

А, ты про то, что индекс должен содержать только один массив? Ну дык правильно все сделано, это не баг, это фича.

гугли flask, блеать! микрофреймворк от создателя шаблонизатора jinja2.

Не понимаю всех криков на Django, мол она никакая и не гибкая. Во первых - она очень мощна, и подходит для многих задач. Главное понимать механизм ее работы, и устройства. В качестве примеров крупных проектов: Яндекс.Афиши. В общем Иван Сагалаев и Александр Кошелев как бы тоже намекают. Крупные проекты на Djange - не миф, а реальность. Но конечно говорить о полной ее применимости - нет смысла. Серебрянных пуль не существует. SQL и NoSQL - разные области применения зачастую. Никто не запрещает использовать только то, или только то. Но тут уже зависит от задачи. Есть задачи, которые вполне могут уложиться в рамки SQL. Pylons - далеко не серебрянная пуля. К примеру Mako. Шаблоны - для верстальщиков, а не для программистов. Заменить на другие шаблоны не трудно - но опять таки, это обход политики фреймворка. Как аналогию Pylons почему то забывают про Werkzeug+Jinja2+SQLAlchemy+WTForms к примеру. Тоже как вариант, и довольно неплохой вариант. На нем строится Svarga - аналог Django на этой связке.

Вариантов перехода куча =) Python: Pylons, Flask, Werkzeug+Jinja2+SQLAlchemy+WTForms Ruby: RoR Groovy: Grails PHP: Symphony Как варианты. =) вопрос в другом. после года постоянной работы с Python, и используя методологию этого языка, и его подходы, стоит ли переходить с него? Думаю, стоит остановится на Python, и если хочется что-то кроме Django, то вариантов опять таки много. =) Главное сохраняется драгоценный опыт Python-программиста. ИМХО =)