Это отличный вопрос и набор отличных ответов. Я думаю, что одна вещь, которая отсутствует в обсуждении, это ответ, который углубляется в различие между базой данных и системой управления базами данных (СУБД). Мне нравится определение базы данных, которое Акула предоставила на dictionary.com. Я думаю, что это действительно показывает необходимость различия между базой данных и СУБД. База данных представляет собой «комплексную коллекцию связанных данных, организованную для удобного доступа». Вторая часть этого определения, которая гласит «обычно в компьютере», - это то, где находится различие. Если он хранится на компьютере, он может храниться или не храниться в СУБД. Может храниться в файловой системе ОС. Может храниться в проприетарной файловой системе. Таким образом, я согласен с FrustratedWithFormsDesigner, что карточный каталог является «базой данных» (ну, может быть - это всеобъемлющее и связанное? Подробнее об этом позже). Это просто происходит в картотеке. В современном мире наиболее «полные» коллекции связанных данных организованы для удобного доступакоторые хранятся на компьютере, так что я не согласен с акулой , что это жаль Dictionary.com добавил , что часть. Я думаю, что это абсолютно правильно - как определение «базы данных».
Итак, как мы определяем СУБД? Я вернулся на dictionary.com и нашел это :
«Набор программ, которые обычно управляют большими структурированными наборами постоянных данных, предлагая многопользовательские возможности специальных запросов. Они широко используются в бизнес-приложениях».
Определение продолжается и довольно долго. В нем описаны общие функции, предоставляемые СУБД, такие как безопасность, целостность данных, управление транзакциями, контроль параллелизма и, самое главное, независимость данных. СУБД обеспечивает внешнее представление данных, абстрагированных от физического их хранения.
Используя это определение, я думаю, что ясно, что СУБД должна предоставлять модель данных , которая является способом, которым данные организованы для представления пользователю. Три общие модели: иерархическая (IMS), сетевая (IDMS) и реляционная (DB2, Oracle, SQL-Server и т. Д.). Существует также модель OO (OODBMS). Только реляционная модель сегодня имеет широкую применимость. Другие модели все еще используются, но только в нишевых ситуациях. СУБД также должна обеспечивать другие упомянутые функции. Я бы назвал их в совокупности функциями или возможностями управления данными.
Следовательно, программные продукты, которые предоставляют функции управления данными, являются СУБД, тогда как продукты, которые не предоставляют их, не являются СУБД. Продукты NoSQL не являются СУБД. Это не значит, что они не полезны, и несказать, что они не хранят "базы данных". Мне нравится думать, что СУБД, как говорится в определении, решает класс проблем, связанных с бизнес-приложениями, такими как бухгалтерский учет, расчет заработной платы, выставление счетов, управление взаимоотношениями с клиентами, продажи и т. Д. Продукты NoSQL, хотя и не СУБД, отлично подходят для решения Класс проблем, которые не связаны с традиционными бизнес-приложениями, но в настоящее время существуют из-за огромного объема памяти и пропускной способности вычислительной техники, которые способны сегодня Это такие приложения, как интернет-поиск, онлайн-аукцион, твиттер и фейсбук. СУБД не подходит для решения этих проблем, так как СУБД содержит функции управления данными, которые, хотя и являются абсолютной необходимостью для бизнес-приложений, бесполезны для решения задач хранения и поиска Крейга. Список рекламы или твиттеры (ну, в любом случае, обычно это еще одно обсуждение :-)). Эти проблемы требуют масштабного масштабирования и чрезвычайно быстрого реагирования, и СУБД с ее раздутыми возможностями не подходит.
Специалист по данным должен понимать все эти инструменты для хранения данных и какие классы проблем они подходят для того, чтобы выбрать правильный инструмент для работы, точно так же, как генеральный подрядчик должен знать, какой из его или ее строительных инструментов является правильный инструмент для работы. Ни один инструмент не является хорошим или плохим сам по себе. Хорошо, если это подходит для решения важной проблемы.
В заключение я отмечу два других ключевых различия в определении как базы данных, так и СУБД, которые могут быть упущены при обсуждении. Определение базы данных включает « полный сбор связанных данных». Определение СУБД включает в себя «управлять большими структурированнымилучше было бы использовать MS Access или какую-либо другую реляционную СУБД. Таким образом, возможно, карточный каталог, в конце концов, не является базой данных, поскольку, будучи всеобъемлющим (он содержит записи обо всех книгах в библиотеке), он не связан, поскольку содержит только информацию о книгах, а не полную связанную информацию об авторах, издателях, и т.п.
Во-вторых, СУБД отлично справляется с хранением «структурированных» данных. Он полностью основан на определенной схеме дискретных элементов данных со структурированными типами. Продукт NoSQL, например хранилище значений ключей, которое не имеет схемы, отлично справляется с хранением неструктурированных данных. Следовательно, этот продукт NoSQL не соответствует определению СУБД. Но если проблема, которую вы пытаетесь решить, - это хранение неструктурированных данных (то, чего мы даже не пытались сделать, когда СУБД были впервые разработаны), и вам не нужны функции управления данными независимо от приложения, в которое вы будете писать обрабатывая эти неструктурированные данные, продукт NoSQL идеально подходит для этого.
Я надеюсь, что этот ответ добавляет ценность другим отличным ответам, опубликованным здесь. Я с нетерпением жду любых комментариев и вопросов для обсуждения, которые могут возникнуть у любого другого человека, которые помогут нам расширить наше понимание баз данных и классов технологий, которые решают проблемы, связанные с данными.