Как смоделировать «справочные данные» в модели базы данных документов?

Question

Я создаю модель документа моих сущностей для хранения в базе данных документов (RavenDB).Домен, который я моделирую, вращается вокруг Incidents.Инцидент имеет источник, приоритет, категорию, уровень воздействия и многие другие атрибуты классификации.В СУБД у меня была бы таблица инцидентов с внешними ключами для таблицы приоритетов, таблицы категорий, таблицы воздействия и т. Д., Но я не знаю, как справиться с этим в базе данных документов (это мой первый Doc BD).

У меня есть два типа справочных данных:

1. Простые значения поиска: Countries, States, Sources, Languages.Атрибуты: у них есть только имя, но это многоязычная система, поэтому есть имя для каждого языка.Поддерживаемые операции: создание, удаление, переименование, деактивация и объединение.

2. Сложные справочные данные: те же, что и для простых поисков, плюс некоторые из них имеют много полей и имеют бизнес-правила и правила проверкиих собственный.Например, два Priorities не могут иметь одинаковое значение Rank.Некоторые имеют более сложную структуру, например Categories состоят из Subcategories.

Как мне смоделировать эти документы как (или как часть) документов?

---

PS: ссылки на Рекомендации по моделированию базы данных документов будетцениться также

Answer 1

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

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

Чтобы ответить на ваши конкретные вопросы:

1. Вы можете сохранить ключ для каждой страны / штата / и т. Д., А затем получить версию для конкретной локали, используя этот ключ, загрузив весь документ справочных данных и выполнив поиск в памяти.
2. Денормализованные ссылки подойдут для категорий. Вы можете включить Имя и / или родительскую категорию, если она должна отображаться. Звучит так, как будто сама сущность маленькая, поэтому вы можете хранить ее целиком (и вам не нужно ее денормализовать). Это нормально для репликации - дешевле обрабатывать таким образом, и это не изменится, или, по крайней мере, не часто (и если это произойдет, вы можете использовать исправления для его обновления). То же самое относится и к другим вашим организациям. Насколько я понимаю, бизнес-правила не имеют ничего общего с базой данных, кроме того, что вы должны иметь возможность выполнять соответствующие запросы для их применения.

Обновление: вот пост, который описывает, как иметь дело с древовидной структурой в Raven .