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

Question

Я разрабатываю новое веб-приложение для нашего бизнеса. Теперь я не знаю, что лучше? Я использую MongoDB в качестве базы данных.

У нас есть около 10 моделей (схем) MongoDB, таких как Leads & Contractors. Модель потенциальных клиентов и подрядчиков должна содержать поле для города и поле в качестве провинции.

Мы хотим показать потенциальных клиентов города «А» для подрядчиков, которые работают в городе «А»;

Как я объяснил, у потенциальных клиентов и модели (схемы) подрядчика должен быть файл для города.

Я хочу знать, какой дизайн является лучшей практикой и почему?

1. Рассматривать город и провинцию как список потенциальных клиентов и подрядчиков (поле города). (Встраивать дизайн).

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

Что лучше и почему?

Answer 1

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

Представьте, что вы хотите запросить подрядчика. Если вы сделали это со ссылками, ваша база данных должна сначала получить документ Исполнителя, а затем приступить к поиску документа City, используя предоставленную ссылку. Встраивание устраняет необходимость в этом, что приводит к гораздо более быстрому чтению. Единственный раз, когда вы захотите рассмотреть ссылки, будет, если у городов будет своя центральная роль в вашем приложении, так как в поле author документа "BlogPost" может быть ссылка на документ "User". Но для простых адресных данных, таких как город и провинция, я предполагаю, что это не так.

Посмотрите эту ссылку https://docs.mongodb.com/manual/core/data-model-design/, чтобы получить четкое объяснение того, когда вставлять и когда разбивать данные на отдельные коллекции со ссылками.