Проектирование базы данных документов: многоуровневые категории (в частности, MongoDB)

Question

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

Сначала я подумал, что документом будет отраслевая группа, и онОтрасли внутри него, но проблема в том, что большая часть связанных данных будет относиться к отрасли.Я не уверен, что «кошерно» иметь данные, относящиеся к подпунктам в документе.Например, статья может быть отнесена к отрасли, а не к группе - так как выглядит эта ссылка (при условии, что ссылка была из не вложенного документа)?

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

Answer 1

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

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

---

Ваш комментарий:

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

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

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

Нет правил структурирования нереляционных баз данных. Это делает их сложнее , чем реляционные базы данных. Извините, но NoSQL - это случай TANSTAAFL !