Коллекции Монго без схемы & C #

Question

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

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

Я подхожу к этому не с того угла? Какие подходы здесь используют участники, чтобы гарантировать, что их элементы коллекции будут синхронизированы с их моделью домена при обновлении их модели домена?

Редактировать: Стоит отметить, что эти проблемы, очевидно, существуют и в реляционных базах данных, но я спрашиваю конкретно о стратегиях по устранению проблемы с использованием баз данных без схемы и, более конкретно, Mongo. Спасибо!

Answer 1

Миграция схемы с MongoDB на самом деле намного менее болезненна, чем, скажем, с SQL-сервером.

Добавить новое поле легко, старые записи будут иметь нулевое значение или вы можете использовать атрибуты дляуправляйте значением по умолчанию [BsonDefaultValue("abc", SerializeDefaultValue = false)]

Атрибут [BsonIgnoreIfNull] также удобен для исключения объектов, которые являются пустыми в документе при его сериализации.

Удаление поля также довольно просто, выможно использовать [BSonExtraElements] (см. документы ), чтобы собрать их и сохранить их, или вы можете использовать [BsonIgnoreExtraElements], чтобы просто выбросить их.

С ними на самом деле нет необходимостичтобы конвертировать каждую запись в новую схему, вы можете делать это лениво по мере необходимости при обновлении записей или медленно в фоновом режиме.

---

PS, поскольку вы также заинтересованы в использовании динамического с Mongo,вот эксперимент Я попробовал в том же духе.А вот обновленный пост с полным сериализатором и десериализатором для динамических объектов .

Answer 2

Я использую mongodb чуть больше года, хотя не для очень больших проектов. Я использую csmongo Хьюго или вилку здесь . Мне нравится динамический подход, который он вводит. Это особенно полезно для проектов, в которых структура базы данных нестабильна.

Answer 3

В языках со статической типизацией, таких как C #, всякий раз, когда объект где-либо сериализуется, затем изменяется его исходный класс, а затем десериализуется обратно в новый класс, вы, вероятно, столкнетесь с проблемами где-то на линии. Это довольно неизбежно, будь то MongoDB, WCF, XmlSerializer или что-то еще.

У вас обычно есть некоторая гибкость с опциями сериализации , например, с Mongo вы можете изменить имя свойства класса, но при этом сохранить его карту значений на то же имя поля (например, с помощью атрибута BsonElement). Или вы можете указать десериализатору игнорировать поля Mongo, которые не имеют соответствующего свойства класса, используя атрибут BsonIgnoreExtraElements, поэтому удаление свойства не вызовет исключение при загрузке старого поля из Mongo.

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

Answer 4

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

Мои репозитории будут иметь минимальную требуемую версию, необходимую для точной сериализации и десериализации элементов коллекций. Если текущая версия БД ниже требуемой версии, я просто выбрасываю исключение. Затем используйте миграции, которые будут выполнять все преобразования, необходимые для обновления коллекций до требуемого состояния, которое необходимо десериализовать, и обновления номера версии базы данных.