RavenDB хорошо подходит для этой концепции? - PullRequest
Новая
       11

RavenDB хорошо подходит для этой концепции?

5 голосов
/ 23 декабря 2011

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

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

Widget
 |- Sprocket
 |  |- A4 nut
 |  |- B15 screw
 |  |- Sprocket Backshell
 |- Flange
 |  |- A4 washer
 |  |- Flange Housing
 |- Widget Assembly

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

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

В настоящее время в SQL Server имеется плохо спроектированная версия этой системы в виде единой плоской таблицы с примерно 120 столбцами и несколькими миллионами записей. Около 85% полей в этой таблице являются пустыми. Моя работа состоит в том, чтобы заменить это чем-то более обслуживаемым, эффективным и менее подверженным ошибкам.

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

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

RavenDB хорошо подходит для этой концепции? Есть ли какие-нибудь указатели на то, как лучше всего это представить в документах?

Ответы [ 2 ]

5 голосов
/ 23 декабря 2011

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

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

  • Какие запросы вам нужны?
  • Что более критично для вашей системы, читает или пишет?
  • Можете ли вы жить с возможной последовательностью?
  • Можете ли вы воспользоваться преимуществами таких функций, как отображение / уменьшение индексов?
  • и т.д.
3 голосов
/ 23 декабря 2011

Похоже, это очень хорошо подходит для реляционной базы данных: 

Part
  - PartId
  - Name
  - ...more fields..

PartRelations
  - ParentPartId (PK)
  - ChildPartId (PK)

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

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

PartAttribute
   - PartId
   - Attribute
   - Value

Атрибут, может быть дополнительно разбит, если вы хотите в другую таблицу Атрибут 

Attribute
   - AttributeId
   - AttributeName
   - ..datatype?.. (for pretty formatting logic or other..)

Тогда в таблице PartAttribute вы можете использовать AttributeId, а не Attribute. На практике я обнаружил, что простое использование строки, а не таблицы атрибутов, которая перечисляет их все, немного проще для кодирования и так же легко поддерживать

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

...