Будет ли MongoDB хорошо подходить для моей отрасли? - PullRequest
0 голосов
/ 24 июня 2011

Я работаю в сфере рекламной продукции.Мы продаем почти все, что вы можете распечатать, вышить, гравировать или любым другим способом, чтобы настроить.Популярными продуктами являются ручки, кружки, рубашки, кепки и т. Д. Поскольку у нас такое большое разнообразие продуктов, хранение информации об этих продуктах, включая все возможные варианты продуктов, варианты оформления и все связанные с ними дополнительные расходы, становится чрезвычайно сложным.Настолько, что, хотя многие пытались это сделать, никто не смог предоставить данные об отраслевых продуктах таким образом, чтобы вы могли алгоритмически превратить данные в хранилище электронной коммерции без некоторой степени массирования данных.Кажется почти невозможным правильно хранить эту информацию в реляционной базе данных. Мне любопытно, позволил бы MongoDB или любой другой вариант NoSQL позволить мне моделировать информацию таким образом, чтобы упростить хранение и манипулирование информацией о нашем продукте лучше, чем в СУБД, такой как MySQL. Компания, которую яРаботает более 100 лет и уже много лет использует DB2 на AS400.Мне понадобятся веские причины, чтобы убедить их использовать нереляционное решение для БД.


Типичным примером продукта, используемого в нашей отрасли, является Bic Clic Stic Pen, у которого более 20 вариантов цвета для каждогобочка и обрезка цветов.Еще больше цветов для шелкографии.Затем вы можете выбрать дополнительные параметры для того, какой тип чернил использовать.Есть несколько вариантов упаковки.После всего, что выбрано, у вас есть дополнительная опция для срочной обработкиВсе эти варианты могут иметь или не иметь дополнительные расходы, которые могут быть основаны на том, сколько ручек вы заказываете или сколько цветов в вашем украшении.Цены, как правило, основаны на количестве, поэтому заказ 250 перьев обойдется дороже, чем заказ 1000. Точно так же дополнительная плата за получение специальных чернил будет дешевле, если заказывать 1000, если вы заказываете 1000, а не 250.

Ответы [ 3 ]

2 голосов
/ 24 июня 2011

Не желая звучать резко, это звучит как вопрос серебряной пули.

У вас сложный бизнес-домен.Мне не ясно, что другой способ хранения ваших данных окажет какое-либо влияние на эту сложность - хранение документов, а не реляционных данных, вероятно, не облегчит оценку стоимости пера на 0,02 доллара ниже, если клиент заказывает более 250.

Я бы рекомендовал сосредоточиться на бизнес-сфере и не слишком беспокоиться о механизме хранения.Я большой поклонник доменного дизайна - это звучит как идеальный случай для такого подхода.

1 голос
/ 24 июня 2011

Да, MongoDB - это то, что вам нужно.Он не имеет строгой структуры документов, поэтому вы сможете создавать набор нужных вам моделей и вставлять их на страницу вашего продукта в любом порядке и комбинациях.На самом деле можно работать с этими данными без непосредственного описания полей реальной модели, поэтому я (например) могу использовать поля, о которых мое приложение Rails вообще не знает.

Кроме того, MongoDB чрезвычайно легко настроить для репликации и разделения.Также он поддерживает виртуальную файловую систему GridFS, поэтому вы можете хранить изображения для ваших продуктов с документами, в которых они описаны, и легко манипулировать ими как одним объектом.

Вы обязательно должны попробовать.

UPD: В любом случае, было бы хорошо сохранить вашу СУБД для финансовых данных и критических чисел, таких как группировка отчетов для анализа продаж и так далее.Основы NoSQL не очень хороши в этом.

1 голос
/ 24 июня 2011

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

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

Однако, это только помогает с данными - ваша реальная проблема на стороне пользовательского интерфейса. Два документа вместе сопоставляются непосредственно с формой заказа, но какой бы метод вы ни использовали для определения опций / правил, для некоторых продуктов будут очень сложные страницы настроек.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...