Говоря конкретно о MongoDB ... потому что база данных не навязывает никаких отношений, таких как реляционная база данных, вы готовы поддерживать любой тип целостности данных, такой как этот.Это чудесно полезно во многих случаях, но в итоге вы пишете больше кода приложения для обработки такого рода вещей.
Сказав все это, они ключом к использованию такой системы, как MongoDB, является моделирование ваших данных для соответствия MongoDB.То, что у вас есть выше, имеет полный смысл, если вы используете MySQL ... используя Mongo, у вас точно будут проблемы, если вы структурируете свои данные, как будто это реляционная база данных.
Если у вас есть Employees
, кто можетработать на одном или нескольких Companies
, я бы структурировал его следующим образом:
// company records
{ _id: 12345, name : 'Apple' }
{ _id: 55555, name : 'Pixar' }
{ _id: 67890, name : 'Microsoft' }
// employees
{ _id : ObjectId('abc123'), name : "Steve Jobs", companies : [ 12345, 55555 ] }
{ _id : ObjectId('abc456'), name : "Steve Ballmer", companies : [ 67890 ] }
Вы бы добавили индекс на employees.companies
, что позволило бы очень быстро получить всех сотрудников, которые работают наданная компания ... независимо от того, сколько компаний они работают.Ведение краткого списка компаний на одного сотрудника будет намного проще, чем ведение большого списка сотрудников для компании.Чтобы получить все данные для компании и всех ее сотрудников, нужно выполнить два (быстрых) запроса.
Разве простота базы данных документов не станет вашим худшим врагом, поскольку она создает хрупкие данныеструктуры, которые не могут быть легко изменены?
Простота может вас укусить, но очень легко обновить и изменить позже.Вы можете создавать сценарии изменений через Javascript и запускать их через оболочку Mongo.