Вопросы Теги

Объединение noSQL и ORM в среде MVC для реального приложения

Я уже некоторое время пытаюсь добавить некоторые «крутые» вещи, которые я читал о noSQL (couchDB, mongoDB, Redis ...), в прошлых лет в практическое использование.

Я привык писать приложения с помощью Django и начал использовать Play! когда Java - единственно приемлемый вариант развертывания (и он тоже наслаждается). У обоих есть модули для работы, например, с MongoDB , а в django также есть nonrel . Но я никогда не чувствовал потребности в noSQL.

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

Пример использования

Допустим, нам нужно управлять порядком и отслеживать (что угодно) некоторые сложные элементы. Предметы могут иметь много разных свойств, например. упрощая, мы могли бы иметь:

  • холодильник, у которого может быть
    • одна или две двери,
    • класс A, B или C,
    • цвет поверхности
    • автономная или встроенная
  • Духовка, которая может иметь:
    • газ или электричество или и то, и другое
    • самоочистку или нет
    • автономную или встроенную

Решение SQL / ORM

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

В моей обычной СУБД через ORM я бы определил модель «продукта», а затем унаследовал две модели, холодильник и духовку. Если через какое-то время холодильник получает еще одно свойство, я изменяю модель и, как таковую, схему, запускаю миграцию и добавляю столбец.

Решения noSQL

Решения noSQL, о которых я могу думать, следующие:

  • с использованием RDF (с чем-то вроде Virtuoso или построением моего собственного упрощенного хранилища троек)
  • с использованием документально-ориентированного БД, такого как MongoDB

Проблема

Но Я не могу понять, насколько другая (более легкая) разработка прагматически будет переключением на решение noSQL, все еще использующее ORM фреймворка с правильным адаптером (особенно с DODB).

Допустим, я использую Django с MongoDB через mongodb-engine.

Я все еще использую ту же ORM, поэтому я все еще описываю эти объекты как модели, перечисляя все свойства. ORM, таким образом, выполняет ту же самую работу! Стоимость создания миграции при изменении модели очень ограничена ORM (в частности, с чем-то вроде South), ничего не требуя изучения новая технология сама по себе.

У DODB могут быть / другие / преимущества и некоторые специфические для MongoDB (масштабируемость, обработка данных, возможно, производительность), но ...как насчет конкретного варианта использования и проблемы, которую я описываю?

Скорее всего, я упустил какой-то момент, так что вот реальный вопрос (-ы):

Для этого конкретного варианта использования:

  • этот пример является хороший или плохой для DODB (у вас есть хороший)?
  • имеет ли смысл объединить ORM для базовых вещей (Пользователи, Заказы) и использование noSQL без ORM для сложных объектов, есть ли веская причина для полного перехода на noSQL, или мне следует остаться со стандартным ORM / SQL?

Я понимаю, что ответ на эти вопросы может быть частично субъективным, поэтому вы можете предположить, что в совершенстве владеете как noSQL, так и теорией SQL, а также ORM; наличие хороших мостов от стандартных ORM к БД noSQL. Предположим, мы говорим об этом варианте использования MongoDB в качестве альтернативы noSQL.

Но есть более общий вопрос - основной вопрос этого сообщения SO:

  • Разве не хорошая ORM (такая как JPA, ActiveRecord или Django), создающая noSQL и, в частности, документно-ориентированные базы данных мало пользы?
  • ... и стоит ли использовать noSQL с «классической» ORM?

(«малопригодность» с точки зрения программирования и обслуживания, производительность и аналогичные критерии - другое дело, и для этого потребуется точное сравнение продукта с продуктом)

[edit]

Я также пытаюсь понять, не лучше ли было бы отказаться от использование ORM при переходе на noSQL. Было бы неплохо иметь более «динамические» модели, например.Я мог бы иметь таблицу, описывающую, что такое модели холодильника и духовки (поля), а модели холодильника и духовки в коде могли бы создавать свои представления динамически (формы для редактирования и списки для отображения).

Связанные вопросы:

[править] : они здесь, чтобы показать мое исследование, но также чтобы прояснить, что я спрашиваю не является общим в отношении noSQL и SQL

РЕДАКТИРОВАТЬ И ссылки:

  • Сиена : API персистентности для Java, вдохновленный хранилищем данных Python Google App Engine, пытающимся нарисовать мост между мирами SQL и NoSQL.
  • minimongo : легкий, бессхемный, объектно-ориентированный интерфейс Pythonic для MongoDB

7
задан Community 23 May 2017 в 12:32
поделиться