База данных, ориентированная на документы (MongoDB?) и выставление счетов/заказов?

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

Как зафиксировать заказ в этом мире? Будет ли заказ просто новым документом в коллекции Orders? Будет ли order_item иметь отношение к product, указанному в другом документе? Или предполагается, что order_item будет скопировано и вставлено в документ заказа, и поэтому, возможно, будет сложно сообщить об общем количестве product, проданных с течением времени?

Как решить проблему отсутствия транзакций и сохранить целостность

Извините, я очень новичок, хотя и хочу понять ... звучит очень привлекательно, чтобы инкапсулировать все эти «вещи» для продажи как «объекты» и перемещать их как таковые между сервером и клиентами и т. д. ... если это действительно правдоподобно. Просто нужна помощь в осмыслении общих правил и запретов.


ruby-on-rails mongodb mongoid document-oriented-db
person Meltemi    schedule 04.02.2011    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Как уловить порядок в этом мире? Будет ли заказ просто новым документом в коллекции заказов?

да. Так работают эти базы данных.

Будет ли order_item относиться к продукту, указанному в другом документе?

Это могло бы. Зависит от того, что вы делаете.

Или предполагается, что order_item будет скопирован и вставлен в документ заказа

Также возможно. Это хорошо работает для исторического анализа и хранения данных.

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

Всегда трудно сообщить об общем количестве проданного продукта с течением времени.

На сегодняшний день продукт "23SKIDOO" - это 23л, открытый клапан, фрамистат с двойными штуцерами.

В прошлом году, до отзыва, таким же продуктом был 23-литровый фрамистат с закрытым клапаном и только одним штуцером.

В прошлом году тот же продукт был на самом деле 22,5 л.

Это "один и тот же" продукт? Маркетинг называет их всех «23SKIDOO». Но есть отличия.

Одна таблица Product не разрешает это правильно. Затем люди изобретают линейки продуктов и семейства продуктов, чтобы они могли представить продукты «23SKIDOO-B» и «23SKIDOO-PLUS», которые являются частью семейства «23SKIDOO».

Линии продуктов и семейства продуктов, а также другие более причудливые группировки — это обходные пути и уловки, позволяющие волшебным образом объединить отчеты о несвязанных продуктах и ​​предоставить «общее количество продуктов, проданных с течением времени», даже если продукты явно различаются.

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

Как можно обойти отсутствие транзакций и сохранить целостность?

MongoDB имеет блокировки. http://www.mongodb.org/display/DOCS/How+does+concurrency+work.

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

person S.Lott    schedule 04.02.2011
comment
полезно, спасибо, и многое в соответствии с тем, что я ожидал. - person Meltemi; 05.02.2011
comment
Теперь, поскольку вы подробно рассказали о том, как обращаться с продуктом, что бы вы сделали, если бы у вас было, скажем, 2-3 разных каталога, в которых нужно было бы указать один и тот же продукт? Части продукта (цена, размер и т. д.) могут отличаться, но вполне возможно, что изменение названия или описания продукта может потребоваться воспроизвести более чем в одном документе. Не выходим ли мы из зоны наилучшего восприятия документо-ориентированных баз данных? - person Meltemi; 05.02.2011
comment
@Meltemi: Может быть. Привередливые теоретические отношения 3NF часто нарушаются в прагматичных проектах баз данных. репликация не является злом по своей сути. Даже в РСУБД часто выполняются репликация и массовые обновления. Если изменение описания продукта задним числом изменит существующие документы, это должно быть частью модели варианта использования. Это на самом деле редко, хотя нам нравится использовать 3NF, чтобы разрешить это. - person S.Lott; 05.02.2011

arrow_upward
1
arrow_downward

Поэтому всегда сложно ответить на общий вопрос. Тем не менее, что я бы посоветовал вам сделать, так это посмотреть на шаблоны чтения и записи, которые вы ожидаете от своего приложения. Существуют компромиссы для определенных дизайнов документов, точно так же, как и для дизайнов схем РСУБД.

Вот ссылка на презентацию дизайна схемы MongoDB. Это может помочь вам понять некоторые из этих компромиссов и вариантов дизайна.

http://www.scribd.com/doc/47326395/MongoBoulder-Schema-Design

person user602502    schedule 04.02.2011
comment
интересная презентация .. узнал несколько трюков ближе к концу, о которых я не знал ... спасибо! - person Meltemi; 05.02.2011