2014-09-26 3 views
2

Я относительно новичок в мире MongoDb, исходя из среды среды MS Sql/Entity.Понимание схемы Mongoose лучше

Я очень рад Монго, из-за:

способность MongoDB для динамического изменения формы класса/таблицы/коллекции во время выполнения.

Entity framework не предлагает мне это.

Почему это так важно?

Потому что я хотел бы создать общую программу инвентаризации и имеют класс продукта/коллекция/таблица быть динамическим для клиентов, чтобы добавить поля, имеющие отношение к их деятельности, которые не могут быть использованы всеми, например. Номер Vin, номер ISBN и т. Д.

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

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

Так вот мой вопрос:

Если я смотрю на разработку универсального класса/сбор/таблица, которая дает клиентам формировать его включать какой бы то ни поля/свойства, которые они хотят, которые имеют отношение к их бизнесу, динамично , я должен отказаться от всего понятия мангуста?

+0

С такой динамической схемой утилита Mongoose довольно ограничена. Какие особенности Mongoose вы хотите использовать? – JohnnyHK

+0

Вот именно. Я прочитал об Mongoose, и я не вижу никакой реальной выгоды от него в MongoDb. Отсюда причина, по которой я задаю этот вопрос. Я имею в виду, если я намерен сильно набирать свои свойства, и в этом случае предопределяю, каковы мои свойства, не возвращаюсь ли я снова к реляционной базе данных? Разве я не теряю все преимущества динамических свойств/полей? – 2014-09-26 13:48:08

ответ

1

Я нашел выгоду сегодня, чтобы, когда схема может быть оправдано:

Позвольте мне предварить, хотя и говорят, что я до сих пор тщательно взволнован о целом идея, что Монго позволяет коллекцию быть изменена при пробеге время в обстоятельствах, когда мне может понадобиться ti. Как уже упоминалось выше, идеальным примером было бы приложение Inventory, в котором я хотел бы, чтобы каждый клиент добавлял соответствующие поля, относящиеся к их бизнесу, в отличие от других клиентов, таких как автосалон, которому требуется поле VIN Number, или книжный магазин, нуждающийся в Поле номера ISBN.

Mongo позволит мне создать один общий стол и позволить клиенту сформировать его в соответствии с его собственными пожеланиями для своей собственной базы данных во время выполнения - SWEET!

Но я обнаружил сегодня, где схема будет appropo:

Если в другой таблице, что не будет «повторно shapeable», скажем, таблицу пользователей, можно создать схему для заранее определенных полей и сделать им требуется, как например:

var dbUserSchema = mongoose.Schema({ 
    title: {type:String, required:'{PATH} is required!'}, 
    FullName: { 
     FirstName: {type: String, required: '{PATH} is required!'}, 
     LastName: {type: String, required: '{PATH} is required!'} 
    } 
}); 

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

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

Смежные вопросы