Движение NoSQL - обоснование для СУБД SQL - PullRequest
3 голосов
/ 05 января 2011

В прошлом году я выполнил множество проектов с базами данных NoSQL на основе json - таких как CouchDB, MongoDB, RavenDB - богатые типы (не хранилища ключей / значений). Я часто общаюсь с коллегами-программистами по поводу моего усыновления, но замечаю, что всегда быстро добавляю: «Конечно, система СУБД SQL по-прежнему имеет место, ее всегда лучше для конкретного проекта / задачи» - как небольшой отказ от ответственности, поэтому ее не увидят как пьющий помощь kool, однако его довольно поверхностное заявление. Помимо устаревших проектов, в которые уже вложены средства в RDBMS или корпоративные мандаты, настаивающие на Oracle, я изо всех сил пытался придумать какой-нибудь будущий проект «зеленого поля», который я бы выбрал для базы данных SQL. Его CouchDB полностью для меня, насколько я могу видеть, с помощью расширенной карты / уменьшения, подачи изменений, поддержки репликации, RESTFUL API (извините, это начинает звучать как плагин)

Мне бы хотелось услышать, как те, кто «получает» (помимо скринкастов) базы данных NoSQL Json M / R, такие как CouchDb, какие типы проектов, по вашему мнению, вы будете использовать MS-SQL, Oracle, Postgresql и т. Д. в будущем?

Спасибо

Ответы [ 2 ]

4 голосов
/ 06 января 2011

Одной из самых сильных сторон SQL является то, что существует стандартный способ моделирования практически чего угодно - для любого конкретного проекта он может не обеспечивать оптимального решения, но он предоставляет разумное решение. Это означает, что в корпоративной среде вы можете решить, что все будет храниться в Oracle, чтобы получить преимущества от обслуживания единой системы без риска того, что она будет совершенно неуместна для будущих проектов.

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

Правильное использование NoSQL обычно требует лучших разработчиков, чем вам нужно для разработки SQL. Один из множества доступных примеров кода SQL может быть отредактирован в рабочую систему кем-то, кто едва знает, что делает. NoSQL делает такие вещи, как устранение проверок целостности для производительности - хороший разработчик создает хорошо протестированный код, который не вставляет недопустимые записи или понимает, почему несколько недопустимых записей не имеют значения для конкретного приложения. Плохой разработчик думает, что все без сообщений об ошибках - хороший код. Среднестатистический разработчик при успешном стартапе в Интернете, вероятно, справится с этим. Средний разработчик, поддерживающий внутренние корпоративные приложения, вероятно, не может.

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

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

2 голосов
/ 05 января 2011

Я бы просто сказал, что если данные по своей природе являются реляционными, СУБД является оптимальным выбором.Например, система управления заказами хорошо подходит для СУРБД.Если данные по своей природе не являются реляционными (например, поисковый индекс Google), то NoSQL - лучший выбор.У них обоих есть свое место.

Мое последнее приложение - массивно иерархическое / реляционное с объектами, содержащими подобъекты, содержащие подобъекты, все связанные естественными ключами.Он идеально подходит для СУБД и был бы намного сложнее в NoSQL DB.

...